Approve and stop should sync sprint-status to ready-for-dev

Problem

In BMAD 6.12, Approve and stop (bmad-build step 02) sets the spec frontmatter status to ready-for-dev and stops before implementation. It does not update implementation-artifacts/sprint-status.yaml.

bmad-build already syncs sprint-status when implementation starts (in-progress) and when review starts (review). Prepare-only therefore leaves two ledgers out of date with each other:

Ledger	After Approve and stop
Spec frontmatter	ready-for-dev
sprint-status.yaml	still backlog (or whatever it was)

Downstream gates that treat sprint-status as the epic-story queue (GitHub promotion, board views) cannot trust a single prepare-only action.

Proposed change

When the human chooses Approve and stop in bmad-build step 02:

1. Set spec status ready-for-dev (already done).
2. If {story_key} is set and sprint-status.yaml exists, run the same sync-sprint-status helper with {target_status} = ready-for-dev.
3. Do not start implementation.

Never-downgrade stays: if the story is already in-progress / review / done, leave sprint-status alone.

Why this belongs upstream

Sprint-status is the machine-readable queue for epic stories. Approve and stop is the documented halt after planning. Those two should agree without a second workflow.

Until this lands, consumers can fail closed on mismatch. Incident Management does that locally (SYNC_SPEC_NOT_READY) and does not invent a BMAD override that would drift from 6.12.

Non-goals

• Do not auto-implement after Approve and stop.
• Do not create GitHub issues from BMAD.
• Do not change bmad-sprint-planning detection of story files.

Context

Observed on BMAD Method 6.12.0. Local write-up: this is a consumer proposal from agrotoken-tech/incident-management, not a patch against this repo.