Bind implementation acceptance to the selected plan revision before activation #2206

Observed behavior

At merge aa81f08dedd0c0943e59db71a0be625e2ea23304, prepareActivation in workflows/shared/squad-activation.mjs selects the latest supported implementation comment but accepts an existing workflow-bot impl-accepted artifact by kind/origin/schema alone. It does not compare the approval's implementation-plan link with the selected plan.

Generic in-memory reproduction reported by an independent consumer reviewer:

1. Origin issue 42 has workflow-bot implementation comment 10, scope acceptance 11, validation 12 and implementation acceptance 13.
2. Acceptance 13 links to implementation comment 10 in its human-readable body. Its standard envelope is {"squad_artifact":"impl-accepted","schema_version":"1","origin_issue":42,"phases":[]}.
3. A newer workflow-bot implementation comment 20 is added.
4. An authorized write actor requests /squad plan activate, with sole activate_plan output targeting plan_comment_id: "20" and a valid synthetic frozen registry/roster.
5. Reported result: capture selects plan 20 and approval 13, preparing one task plus an epic. No APIs or writers were invoked.

The source coordinator independently confirmed the selection logic and compared the pre-repair source at fc1cf596c1429f4c9ff7a99b90acd85d02cfdac2. That source already used existence-only implementation acceptance, while acceptance instructions described locking an implementation plan and including its link. This is a pre-existing revision-binding gap, not a demonstrated regression introduced by #2204. No newly mandatory digest field is assumed.

Expected correction

Before creating issues, require implementation acceptance to correspond to the selected implementation revision. Define the compatibility behavior for existing standard artifacts using their supported plan-link representation; do not assume invented proof fields or silently treat an unrelated old approval as current. Preserve authorization and no-create recovery guarantees.

Regression coverage

Use standard synthetic producer-shaped artifacts. Cover matching accepted revision, newer unaccepted revision, missing/ambiguous/stale links, and phase acceptance. Mismatched acceptance must reject before reservation or issue creation. Keep current valid activation and recovery paths passing.

Disposition

Tracked independently from the already-merged activation-integrity repair. The demonstrated mismatch is real, but baseline comparison does not establish an adoption regression. This issue is not a claim that approval freshness is verified today, and does not authorize consumer-local patches, permission changes or a new attestation scheme.