fix(execution): cancelling twice must stay idempotent

[dovvnloading]

The problem

Self-review of #266 found a regression that PR introduced, plus three smaller
things it got wrong. CI was green on all seven jobs, so none of this was caught
by the existing suite.

The regression. #266 made cancelling a one-way state in the execution
store. It left cancelling unreachable from itself -- but request_cancel()
writes status="cancelling", so a second Stop raised
ExecutionTransitionConflict. routers/execution.py maps that whole error
family to 404, so pressing Stop twice told the user "Execution job not
found". Clicking Stop twice is an ordinary thing to do when a local model is
slow to react.

No existing test double-cancels, which is exactly why it slipped through.
Reproduced before the fix:

first  cancel: cancelling
second cancel: ExecutionTransitionConflict: Execution job is cancelling and cannot become cancelling.

What changed

_CANCELLING_EXITS gains cancelling, so a repeated cancel is idempotent
while nothing non-terminal may still follow a committed cancellation. The new
test fails against the previous frozenset and passes with it, and it re-asserts
the original invariant (a running write is still refused) so the fix cannot
be widened by accident later.

Three smaller corrections from the same review:

1. An impure React initialiser. fix: nine correctness defects in cancellation, consent, time, and startup #266 wrote the handoff secret to
   sessionStorage from inside readLauncherCredentials, which runs from a
   useState initialiser. The comment immediately below that function explains
   why the URL scrub was moved out of the initialiser: React documents
   initialisers as pure and StrictMode double-invokes them to surface impure
   ones. The write now happens in the effect that already performs the scrub,
   and the docstring no longer claims a purity it did not have.

2. An overstated claim. fix: nine correctness defects in cancellation, consent, time, and startup #266's message said a Stop pressed during
   translation returns the finished answer. It did not: the cancellation check
   was skipped only when translation had also failed, and the API runner
   discards the result whenever the cancel event is set, so nothing
   user-visible changed either way. The check is unconditional again and the
   comment now says what actually happens, and where keeping finished work
   across a cancellation would genuinely have to be fixed.

3. A trap left behind. The legacy JSON migration's fallback timestamp was
   still naive, and storage._utc_now() survived with no callers -- ready to
   quietly reintroduce the zone-less writes fix: nine correctness defects in cancellation, consent, time, and startup #266 removed. Both are gone; read
   normalisation already covered the display side.

Verification

./scripts/check.ps1         All 10 checks passed in 108.6s
python -m pytest -q         950 passed
python -m mypy              Success: no issues found in 79 source files

The idempotence test was confirmed by reverting the one-line fix and watching
it fail, then restoring it.

Risk

Narrower than #266. The store invariant is relaxed in exactly one direction
(cancelling to itself); recovery writes its cancelled rows through direct SQL
rather than transition(), so it was never affected by either version. Rollback
is a revert of this single commit, which restores #266's behaviour including the
double-cancel defect.

🤖 Generated with Claude Code