Run the initial setup steps as one chain. #246

What problem does this address?

The setup checklist runs the clone automatically, then waits for the contributor to start the next three steps by hand: Install npm dependencies, Run full build, Start dev server & finish wizard. Each unlocks the next, so there is no decision to make in between — just noticing a step finished and clicking the next button. #44 makes the wait worse, since the idle step reads IN PROGRESS.

The app already runs this chain automatically elsewhere. src/renderer/update-plan.cjs has planUpdateSteps (fetch → install → build) for trunk updates (#94) and planApplySteps (apply → install → build) for applying a patch (#11). Both share updateStepStatuses for progress and updateOutcome for how the chain ended, and both are covered by test/update-plan.test.cjs. Initial setup is the only flow that still asks the user to drive install and build themselves.

What is your proposed solution?

Make setup a chain of the same shape — clone → install → build → start dev server — reusing the existing modules rather than adding a second mechanism. updateStepStatuses already returns the complete / current / pending / skipped states the checklist needs, and takes its state→step map as a parameter so another chain can reuse it. A planSetupSteps alongside the other two would fit.

The chain starts on its own once the clone finishes — no button to press. That is the point of a setup wizard: a contributor who walks away during the clone should come back to a finished environment, not to a checklist waiting on them.

What it needs to get right:

• Be interruptible, with visible progress. This is the condition that makes auto-start reasonable. Starting the dev server re-runs the whole production build (~30 min on Windows) #72 measured the full build at ~30 min on Windows, and First build runs the full production build when a dev build would do; a crashed build still counts as built #92 notes it runs a production build where a dev build would do — so the contributor needs to see which step is running and be able to stop the chain.
• Stop at the first failure. updateOutcome already has the state for it (incomplete). A failed install keeps its retry and does not unlock the build (see Initialization wizard treats partial npm installs as complete and prevents recovery #42).
• Keep terminal output visible — Run first full build hides npm output and failures from the visible terminal #41 was this exact problem with a single step.
• Fixing First build after Install npm dependencies pays a redundant nested npm install (install-changed's packagehash.txt is never seeded) #57 (redundant nested npm install between the two steps) gets easier once they are one run.

The existing Skip initialization wizard link should still be available for anyone who wants the manual path.

Relationship to #44

These two are connected, and this issue changes what #44 has to fix.

Once the chain runs on its own, a step is only current while its process is genuinely running — so In progress becomes true and the ambiguity #44 describes disappears on the happy path.

It does not remove #44. Where a chain stops still needs honest labels: the step that failed, and the ones after it that never started. #44's proposed state model (complete / running / ready / locked / failed) is what makes that legible, so the two should land together or #44 first.