Add exit-code tests for extracted github-agile scripts (deferred)

[sebastientaggart]

Problem to Fix

The mechanical-sequence extractions under #163 (and the existing sync-base-branch.py from #162) are landing without automated tests. Their behaviour is currently validated by hand each time a skill workflow is exercised end-to-end. That works while the surface is small and the scripts are new, but the longer it stays that way, the more behavioural drift can creep in unnoticed — a fix to one script silently changing the contract another caller depends on.

Why it Matters

• Regression safety. Each script wraps a permission-sensitive shell sequence — silent breakage in argument handling, exit codes, or error messages is exactly the kind of thing manual exercise will miss until a real workflow hits the edge case.
• Documentation by example. A small exit-code test file is the most precise record of "what does this script promise its callers" — much better than re-reading the skill markdown.
• Cheap once the shape stabilises. Each script is ~50 lines with a small number of branches. The test cost is low; the deferred-payoff risk is the only reason not to write them on day one.

General Approach

After the extracted scripts have lived in production for a few weeks (long enough to surface real-world usage patterns and let their shape settle), add minimal exit-code tests for each script under tests/.

Scope per script:

• One success-path test (mock the underlying gh / git invocation, assert exit 0 and that the command was constructed correctly).
• One test per documented non-zero exit code (bad args, missing input, subprocess failure).
• No need for full integration tests against live GitHub — the goal is contract pinning, not end-to-end coverage.

Use the existing tests/test_sync.py as a structural reference (uses unittest, lives at repo root). Either add one file per script (tests/test_post_issue_comment.py, etc.) or group by skill (tests/test_github_agile_scripts.py) — pick whichever is lighter once the count is known.

Wire into whatever test runner the repo settles on (currently python3 -m unittest discover tests works).

Complexity

Verification / QA effort: trivial

Tests are self-verifying by definition; the only manual step is confirming the test runner picks them up.

Acceptance Criteria

• Every Python script under skills/github-agile/scripts/ (and any sibling group directories created by then) has at least one success-path test and one test per documented non-zero exit code.
• Tests live under tests/ and run via the project's standard test command (currently python3 -m unittest discover tests).
• Tests do not require network access or a live GitHub repo — subprocess.run is mocked or the script is invoked in a temp git init directory as appropriate.
• This ticket is intentionally deferred — do not open until Audit github-agile skills and extract all remaining mechanical sequences into Python scripts #163's audited extractions are largely complete and have been in use long enough that their shapes are stable.

[sebastientaggart]

Investigation Findings

• bump-and-tag.py documents an unreachable exit code. Its docstring lists 4 bad arguments, but the script parses args with argparse (required=True), so missing/invalid arguments are intercepted by argparse itself, which exits with code 2 — main() never returns 4 anywhere. Exit 4 is dead documentation.
• Action taken in this PR: the exit-code tests pin the actual behavior (bad args → SystemExit code 2), and the bump-and-tag.py docstring is corrected to remove the phantom 4 and document the real argparse exit. No behavioral change to the script.
• All other seven scripts' documented exit codes are reachable and are covered by tests.

[sebastientaggart]

Resolution

Each of the eight helper scripts that power the Code Cannon workflows now has a small automated test confirming it behaves correctly — succeeding when it should and failing with the right signal when something is wrong (bad input, a missing file, a GitHub or git command that fails). These run instantly with the project's normal test command and need no internet or live repository, so any accidental change to how a script behaves will now be caught automatically instead of surfacing mid-workflow. Along the way we corrected a small inaccuracy in one script's documentation.

See #212 for full technical details.