Reconsider whether the next-action cue should reach beyond the setup checklist

The question

Should the next-action cue point at anything outside the setup checklist?

Today it does. deriveNextAction is a priority ladder across the whole site view — incomplete update, stale trunk, applying, staged preview, start dev server, review changes, link ticket — and #256 wired every one of those to a cue target. That was deliberate and finished #252.

Why it is worth revisiting

The cue earns its place in the checklist. Four rows, three of them inert, and the glow says which one is live. There is real competition for attention.

In the post-init view there often is not. A site that is initialized, not running and has no other pending state shows a glow around Start dev server — which is already the only primary button on the screen. The cue is marking something that was not ambiguous.

The effect is easier to see now that #277 has given the dev-server button the stock WPDS shape: a square button inside a rounded glow reads as an outline more than as emphasis.

What a change would have to cover

Not just deleting cueProps calls:

• The role="status" aria-live="polite" region announces Next step: <reason> as the cue moves. If the cue stops reaching the post-init view, that announcement has to stop too, or it describes something with no visible counterpart.
• The cue hook scrolls its target into view. Same question.
• test/next-action.test.cjs covers the full ladder. Narrowing the cue does not necessarily mean narrowing the resolver — the ids could keep being derived and simply not rendered — but which of the two is being changed needs deciding.

Options

1. Leave as is. The resolver picks one target and the glow is never ambiguous, which is what #252 asked for.
2. Checklist only. The cue renders only for setup-* ids. The resolver keeps its ladder; the post-init panels stop consuming it.
3. Keep it, but only when there is competition. Cue the post-init view only where more than one action is genuinely available — the hardest to specify, and the easiest to get wrong.

No strong recommendation. Raising it because it came up while looking at the header with fresh eyes, and because the case for the cue is visibly weaker in one half of the app than the other.

Related

Follow-up to #252, #254, #256, #260, #263. Noticed during #277.

Start with deriveNextAction, the cueProps consumers, and test/next-action.test.cjs; trace how setup-* and post-init targets reach the cue. Decide which option is intended, then verify the status announcement and scroll hook stay aligned with the visible cue, with tests covering the chosen resolver and rendering behavior.