gh-aw: plan activate binds a task's squad:{agent} label from its epic owner, not the task's Agent cell #1859

Summary

During the E4 end-to-end run on the live fixture, /squad plan activate minted a task's squad:{agent} label from its epic's owner rather than from the task's own Agent cell in the accepted implementation plan. 11 of 12 tasks bound correctly; task 6 drifted.

This is an agent-binding correctness bug in the same family as #1784 / #1801 — but it survives all existing guards, because TG-2 certification and validation Check 10 both pass: the label applied is a certified roster name, just the wrong one.

Evidence

Fixture: octodemo/aspiregregator-squad-e2e, seed issue #5, activation run 32778953402 (all six jobs success).

Accepted implementation plan (comment 5400751833, the artifact locked by /squad plan accept implementation):

| 6 | Reconcile `MostRecentItems` by `Link` on refresh | M | — | McManus | 2.1 |

Issue actually created for that task:

#17 [squad,squad:kint] Reconcile MostRecentItems by Link on refresh
**Context:** Epic 2.1, D4 · Size M · Depends on: —

Epic 2.1's suggested owner in the program plan is Kint. The task's Agent is McManus. The minted label followed the epic, not the task.

All other 11 tasks matched their Agent cell exactly:

Why existing guards miss it

• TG-2 (workflows/squad.md:456) certifies the roster set. kint is certified, so minting squad:kint is permitted.
• Validation Check 10 (workflows/squad.md:1175-1185) asserts every Agent value is a member of the roster set. It validates membership, not correspondence — it never compares the minted label against the specific task row it came from.

So a label can be simultaneously "certified" and wrong. The guards prove the vocabulary; nothing proves the mapping.

Expected

workflows/squad.md:928 says the label is squad:{owner} where {owner} is the row's Owner. For a task issue, the authoritative value is that task's Agent cell in the accepted implementation plan — not its epic's suggested owner, which is explicitly advisory ("suggested owner").

Suggested fix

In the activation roster-binding gate (workflows/squad.md:1310-1329), bind each task issue's squad:{agent} label from the task's own Agent cell, keyed by task number, and add a per-row correspondence assertion: for every created task issue, the minted squad:{agent} must equal the accepted plan's Agent for that task number. A mismatch should be a reported binding failure, not a silent substitution.

Worth considering as a deterministic check rather than a prose rule — this is exactly the shape of the non-model checker discussed in #1801.

Repro

1. Run the full path on a fresh fixture through /squad plan activate.
2. Diff each created task issue's squad:{agent} label against the accepted implementation plan's Agent column, keyed by task number.
3. Any task whose epic owner differs from its own Agent is a candidate for drift.