Point the contributor at the next action in the post-init view - #256

## Why

The initial setup checklist labelled the **current** step "In progress"
the moment it became the next actionable step — before the contributor
clicked anything and before any work was happening. On a fresh site,
*Install npm dependencies* announced itself as "In progress" while
nothing was installing (#257), which reads as "the app is already doing
this" and invites a contributor to wait instead of clicking. The
next-action ring (#252) made it worse by drawing the eye straight to the
wrong word.

## What changes

Root cause: the checklist's `current` status — "first ready, not-done
step" — always mapped to the "In progress" label, conflating *next* with
*running*. The running signal (`installing` / `building` / `starting`,
and `isPending` for the clone) already existed for the buttons but the
label ignored it.

- New pure `setupStepLabel(status, isRunning)` in
`src/renderer/setup-steps.cjs`: a current step reads **"Ready"** until
its action is under way, and **"In progress"** only once it is. Other
statuses keep their fixed words.
- The render passes each step's own running flag (download↔`isPending`,
install↔`installing`, build↔`building`, dev↔`starting`).
- Removed the now-dead `label` keys from the `checklistVisuals` object
so the status word has one source of truth (the object keeps only
colours/indicator).

## How to test this

**Platforms:** any (renderer-only). Stacked on #254 + #256 — test this
branch's Buildkite artifact to exercise all three.

**Starting state:** a freshly created site, on the **Initial setup
checklist**, clone finished.

1. Look at the current step (*Install npm dependencies*) before
clicking. → It reads **"Ready"**, not "In progress".
2. Click **Install npm dependencies**. → While it runs, the status reads
**"In progress"**.
3. Let it finish. → Install reads **"Completed"**; **Run full build**
becomes current and reads **"Ready"** (not "In progress"). Repeat for
build → dev.
4. While the initial clone is still running (a brand-new site), the
**Download** step reads **"In progress"** — because it genuinely is.

**What must not have happened:**

- No step reads "In progress" while its button is idle and clickable.
- Completed / pending / locked steps are unchanged ("Completed" /
"Pending" / "Locked").
- The next-action ring and scroll (from #254/#256) still behave exactly
as before — only the status word changed.

## Risks and limitations

- Renderer-only; no behavioural change beyond the status word. Not
hand-verified by the author (no local app run — the repo's EBADENGINE
install constraint); `eslint .` is clean and `npm test` passes (**794**,
incl. 3 new for `setupStepLabel`). The Buildkite artifact is the
hand-test path.

## Related

Closes #257. Stacked on #256 (base branch
`juanmaguitar/next-action-post-init-panels`), which is stacked on #254.
Merge #254 → #256 → this.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

**No findings across the five dimensions** (0 [fix here] · 0
[follow-up]). Judgement pass ran in a fresh `Explore` subagent given
only the diff and the review standard, per `/self-review`.

Verified: only `complete`/`current`/`pending`/`locked` reach the switch,
so `default` is exclusively `current`; each step's `running` flag
matches the flag that drives its own button (and `isPending` for the
clone, which is the only time download is `current`); no other reader of
the removed `visuals.label` remains; the `running` spread never collides
with `computeSetupStepState`'s keys; and the new tests fail on the old
hard-coded "In progress" behaviour.

Deterministic layer: `eslint .` clean; `npm test` **794 pass** (3 new).
Both run in the worktree with node_modules symlinked.

</details>

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

## Why

The next-action cue (#252) points at the block a contributor should act
on next. A block that is *doing* work — a trunk update, a patch apply or
revert — is where attention belongs too: it should scroll into view and
glow like any other cue target, so a contributor who looked away can see
where the work is and that it isn't stuck. The trunk-update tracker was
already highlighted; this completes the idea so **any block displaying
work in progress** gets the same treatment.

## What changes

- `next-action.cjs`: a new high-priority rule — when `isApplying` is
true, point at the `applying-patch` block (the patch apply/revert step
tracker). It sits above the stale-state warnings: a live operation
outranks a warning. One flag covers both operations — a revert runs
through the same apply machinery (`runApply({ reverse: true })`), so
there is no separate "reverting" id.
- Reordered the ladder so the two in-flight, tree-owning operations
(`isApplying`, `isUpdating`) are checked before `updateIncomplete`, and
dropped the now-redundant `!isUpdating` guard. Behaviour-preserving for
the pre-existing cases.
- `index.jsx`: passes `isApplying` to the resolver and spreads
`cueProps('applying-patch')` onto the tracker (the block that only
renders while the operation runs).

After this, every in-progress block in the site view is a cue target:
the trunk-update tracker (wired earlier in the stack) and the patch
apply/revert tracker (here). Each glows and — with the assertive scroll
from the base PR — is centered in view when it starts, and the cue
clears when it ends.

## How to test this

**Platforms:** any (renderer-only). Stacked on #254 + #256 + #258 — test
this branch's Buildkite artifact to exercise the whole stack.

**Starting state:** an initialized site, wizard skipped, with the *Apply
a patch or PR* panel visible.

1. Apply a PR or a `.diff`/`.patch` file (paste a PR URL → **Apply PR**
→ **Apply and rebuild**). → While it runs, the **step tracker block
glows** (soft amber) and the view scrolls to center it.
2. Let it finish. → The glow clears from the tracker (the block
unmounts); the cue moves on to the next pending action.
3. With a patch applied, click **Revert this patch**. → The same tracker
block glows while the revert runs.
4. Trigger **Update to latest trunk** (on a stale site). → Its progress
tracker glows and scrolls into view the same way — confirming the
treatment is general, not apply-only.

**What must not have happened:**

- The glow must not linger after an operation ends (the tracker unmounts
when `isApplying` is false).
- While applying/reverting, the cue must be on the tracker — not on
start-dev / review-changes / link-ticket.
- The screen-reader live region announces "Next step: A patch is being
applied or reverted."

## Risks and limitations

- `isApplying` and `isUpdating` own the working tree and never run at
once (each disables the other's controls), so the ordering between them
is not observable in practice; `isApplying` is placed first regardless.
- Renderer-only. Not hand-verified by the author (no local app run — the
EBADENGINE install constraint); `eslint .` clean, `npm test` **796** (2
new). Buildkite artifact is the hand-test path.

## Related

Part of #252. Stacked on #258 (base branch
`juanmaguitar/setup-step-ready-label`) → #256 → #254. Merge bottom-up.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

**No findings across the five dimensions** (0 [fix here] · 0
[follow-up]). Judgement pass ran in a fresh `Explore` subagent given
only the diff and the review standard, per `/self-review`.

Verified: `isApplying` is true for both apply and revert (`runApply`
sets `applyState` unconditionally, revert calls
`runApply({reverse:true})`); the ladder reorder is behaviour-preserving
across all `updateIncomplete`/`isUpdating` combinations, and dropping
the `!isUpdating` guard is safe now that `isUpdating` is checked first;
the two tree-owning operations are mutually exclusive (both bail on the
shared `running` flag), so `isApplying` winning is moot in practice and
reasonable otherwise; and the `applying-patch` id and its DOM block
appear/disappear together (`cueProps` in scope).

**One change applied from the review** (a style note, not a finding):
removed a second test that fed the resolver the same input as the first
— the apply/revert distinction lives in `runApply`, not the resolver, so
a resolver test can't prove it. Kept one test documenting the
shared-flag behaviour.

Deterministic layer: `eslint .` clean; `npm test` **796 pass** (2 new).

_Note: reviewed as the apply/revert-specific change; the reframing to
"any block showing work in progress" is a title/description change only
— no code changed since review._

</details>

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

## Why

When a contributor pastes a PR or picks a `.diff`/`.patch` file, the app
shows a **staged preview** — "<label> changes N files" with **Apply and
rebuild** / **Cancel**. That block is a clear next action: they set it
up and the decision to apply is theirs. But it was not a cue target, so
nothing pointed at it. This highlights it like the other next-action
blocks.

## What changes

- `next-action.cjs`: a new rule — when `applyPreview` is staged, point
at the `apply-preview` block. Placed **after** the in-flight operations
(`isApplying`, `isUpdating`) and **before** the stale-state warnings and
routine steps: an explicit, waiting choice beats a standing suggestion,
but a live operation still wins. The ordering matters — the preview
block renders only under `applyPreview && !isApplying`, so once applying
starts the cue must move to the progress tracker; checking `isApplying`
first guarantees the id follows the visible block.
- `index.jsx`: passes `applyPreview` to the resolver and spreads
`cueProps('apply-preview')` onto the preview block.

## How to test this

**Platforms:** any (renderer-only). Stacked on #254 + #256 + #258 + #260
— test this branch's Buildkite artifact to exercise the whole stack.

**Starting state:** an initialized site, wizard skipped, *Apply a patch
or PR* panel visible.

1. Paste a PR URL (or number) and click **Apply PR** — or choose a
`.diff`/`.patch` file. → The **preview block** (with *Apply and rebuild*
/ *Cancel*) glows and the view scrolls to center it.
2. Click **Apply and rebuild**. → The preview unmounts and the glow
follows to the **progress tracker** (from #260).
3. Instead, click **Cancel**. → The preview clears and the cue moves on
to the next pending action.

**What must not have happened:**

- The glow must not stay on the preview once applying begins (the
preview block is gone by then).
- No glow on the preview when there is nothing staged.
- Screen reader announces "Next step: A patch is staged — apply and
rebuild, or cancel."

## Risks and limitations

- Renderer-only. Not hand-verified by the author (no local app run — the
EBADENGINE install constraint); `eslint .` clean, `npm test` **799** (3
new). Buildkite artifact is the hand-test path.

## Related

Part of #252. Stacked on #260 (base branch
`juanmaguitar/highlight-patch-progress`) → #258 → #256 → #254. Merge
bottom-up.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

**No findings across the five dimensions** (0 [fix here] · 0
[follow-up]). Judgement pass ran in a fresh `Explore` subagent given
only the diff and the review standard, per `/self-review`.

Verified: the resolver checks `isApplying` before `apply-preview`, so
when applying starts the preview block unmounts and the cue follows to
the progress tracker in the same render (locked by a new test);
`Boolean(applyPreview)` is the right null-vs-object coercion, and the id
is returned only when the preview block is actually rendered (no
id-without-block window); `cueProps` in scope; full suite green. The
reviewer also confirmed a staged preview + in-flight trunk update can
coexist and `updating` correctly wins — placing `apply-preview` below
`isUpdating` is intentional, and the cue still lands on a rendered
block.

Deterministic layer: `eslint .` clean; `npm test` **799 pass** (3 new).

</details>

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>