state tracking: AC-level scope reduction must invalidate story-level "unblocks X" claims

## Observed

Story N shipped with one AC delivered as an explicit NotImplemented stub (itself the correct adjudicated remediation of an adversarial finding — gate explicitly rather than expose a mis-coded stub). Downstream pipeline state (STATE.md drift items, resume checkpoints, task tracking) recorded "Story N MERGED → evaluation phase hardware-half UNBLOCKED" because the story as a whole was the named unblocker. The stubbed AC was exactly the capability the hardware evaluation needed. The human operator sat down for the scheduled hardware window, ran the command, and hit the stub live — burning an operator session on a false unblock.

## Engine gap

Unblock claims are tracked at story granularity ("STORY-N merged") while delivery reality is AC-granular. When an adversarial remediation or scoping decision converts an AC to an explicit stub, nothing in per-story-delivery or the state-manager templates forces re-validation of downstream claims that name the story as an unblocker. The MERGED status is true; the unblock inference from it is not.

## Suggested fix

Two candidate mechanisms (either suffices):
1. Per-story-delivery close-out step: enumerate ACs shipped-as-stub / descoped, and require the orchestrator to re-check any STATE.md drift item or blocked task citing this story as unblocker, downgrading claims that depended on the stubbed AC.
2. State-manager template rule: "unblocked by STORY-N" entries must cite the specific AC(s), so the close-out diff between promised and delivered ACs mechanically surfaces stale claims.

## Evidence

Session 2026-07-06, private consumer project: hardware evaluation half recorded as unblocked by a story merge; the gating AC had shipped as an explicit stub; discovered at operator keyboard time; a follow-up story was opened to deliver the stubbed AC properly.