Fix Crane completion gating

[mrjf]

TL;DR

Refs #78. This makes Crane completion two-phase: reaching the migration target metric creates a completion candidate, but final completion requires the current pushed PR head checks to be terminal success. It also lets the scheduler recover issues that were already moved to crane-completed when their PR-head gate is not actually green.

Problem

Issue #78 could be marked crane-completed even though PR #102 still had a failing parity gate. Once crane-migration was removed, the issue stopped being discovered by scheduled Crane runs, so no follow-up work happened.

Approach

• Treat target-metric as a candidate signal, not a final completion signal.
• Add explicit state fields for Completion Candidate, Completion Gate, and Completion Gate Status.
• Require current PR-head check runs to be completed with success before swapping crane-migration for crane-completed.
• Teach the scheduler to fetch open crane-completed issues too, evaluate their current PR head checks, and re-select stale completed issues whose gate is missing, pending, or failing.

Implementation

File	Change
.github/workflows/crane.md	Documents the two-phase completion flow, PR-head gate, stale completion recovery, and label restoration behavior.
.github/workflows/scripts/crane_scheduler.py	Discovers crane-completed issues, evaluates exact PR-head check runs, and treats failing completed-label issues as due work.
tests/unit/test_crane_scheduler.py	Adds regression coverage for label parsing and PR-head check gate pass/fail behavior.
tests/unit/test_crane_workflow_prompt.py	Adds prompt assertions for candidate state, stale completion recovery, and gate fields.

Trade-offs

• This uses check runs on the PR head as the deterministic scheduler-side signal. Commit status contexts are not separately evaluated yet.
• If GitHub check-run data is unavailable, the scheduler does not invent a pass; it leaves the completed issue alone unless it can prove the gate did not pass.
• gh aw compile could not be run locally because gh is not installed in this environment. The source workflow body changed; the current lock file runtime-imports the workflow body, but CI should still run the official lock check.

Validation

python3 -m pytest --noconftest tests/unit/test_crane_workflow_prompt.py tests/unit/test_crane_scheduler.py -q
............                                                             [100%]
12 passed in 0.08s

PYTHONPYCACHEPREFIX=/private/tmp/apm-pycache python3 -m py_compile .github/workflows/scripts/crane_scheduler.py tests/unit/test_crane_scheduler.py tests/unit/test_crane_workflow_prompt.py
# passed

git diff --check
# passed

Blocked locally:

gh aw compile --no-check-update
zsh:1: command not found: gh

PYTHONPATH=src python3 -m pytest tests/unit/test_crane_workflow_prompt.py tests/unit/test_crane_scheduler.py -q
ModuleNotFoundError: No module named 'click'

How to test

1. Open an issue migration with target-metric: 1.0 and an existing Crane PR.
2. Let Crane reach the target metric while the PR head checks are pending or failing.
3. Confirm the issue keeps or regains crane-migration, does not keep crane-completed, and records a pending/failing completion gate status.
4. Make the PR head checks all pass.
5. Confirm the next Crane run finalizes completion and only then applies crane-completed.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com