Stop takes no lock, so a start in another window fails #125

Blocked by #118 (status model) and #124 (stop goes through the lock).

Problem. runStop/stopStone (src/lifecycle.ts, src/processes.ts) take no stone lock. A notebook cell, the Shell or the wrapper asking for the database while another window stops it sees the stone listed and doesn't start it. With #118 the waiter then fails with a shutting-down / "stopped" error and nothing restarts it. In telemetry this is a startFailed in the other window. A root-path change while bring-up runs has the same shape.

Not obvious:

• A stopping stone passes through Startup. Measured on 4.0.0.a4 (3/3 runs): OK, Shutdown, Startup (20-40 ms), gone. A waiter can therefore see Startup at the very end of a stop and treat it as a stone that is starting up, and wait for it. Start the stone and session listener once, across processes #118 waits through startup/recovery and fails fast on shutdown, so it has to tell these two apart.
• A stop must not be waited out by a start that then restarts it. The user pressed Stop; a start that begins afterwards, in the same or another window, is a separate decision.

Scope:

1. Decide the policy and write it down. Candidates: a start that finds a stop in progress waits for it, then starts; or refuses with a message saying the database is being stopped. The same policy covers a root-path change.
2. runStop/stopStone take the stone lock (the unified one from One lock mechanism for TS and bash, with a nonce and a heartbeat #124), so a start and a stop can't interleave.
3. The waiter's "shutting down" failure becomes the chosen behaviour, not an error the other window reports as startFailed.
4. CHANGELOG entry.

Manual check:

• Press Stop in one window while a notebook cell in another asks for the database: the cell gets the defined outcome, not "Starting GemDB failed".
• Same with the Shell and with gemdb -c ....