F1b: runner coordinator for attempts, slots and shutdown (#74)

* F1b: runner coordinator for attempts, slots and shutdown

In-memory jobs with two-step admission and a slot reservation;
abortable preparation with task-budget and deadline timers; a
synchronous launch check before D's start; first-reason stops that keep
the slot until D settles; Store-chosen terminal states; unresolved markers
on storage failure; cancel task; and shutdown that keeps existing reasons
and waits for every job.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Pass D's runnerOwner through the runner coordinator

Lane D (#71) made runnerOwner a required InvocationInput field and refuses
task storage owned by another runner. The injected D now supplies the
token in RunnerDeps, so preparation and the start call use the same one.
F1d replaces the source with the per-database runner token.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Refuse new work after unreleased resources; never strand a live handle or an admitted job

- D settling with `unreleased` closes the runner to new work until restart, as Ask does.
- A failed read after a refused markRunning no longer abandons the running handle.
- Arming the timers moves inside the job, so a failed budget read ends the attempt instead of leaving it stuck.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Remove preparation files after a saved terminal write; keep the stale cause and the preparation timeout text

- After D settles and the terminal write succeeds, remove the host-side preparation files before freeing the slot.
  A failed terminal write leaves them for startup recovery.
- stop(..., 'stale', cause) keeps the cause; the agent's stderr is never recorded as the reason an attempt went stale.
- A preparation timeout passes no D stop reason, so the row keeps "Timed out while preparing." as the spec requires.
- Tests: the shutdown-keeps-reason case now covers an unsaved reason, which the durable row cannot repair.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Keep the runner closed at launch, keep a preparation timeout, and check the context first

- The launch check refuses to start D once unreleased resources were reported, even for an already admitted attempt.
- After the attempt deadline passes before launch, a later stop (shutdown, time limit) cannot replace the timeout.
- The launch check tests the context before the time checks, so a changed context ends stale, as the spec orders it.
- A stop after the terminal write, while only cleanup remains, is refused instead of setting a reason on a settled attempt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Keep the job's reason in step with a cancel task the Store recorded; cover preparation failure and the held slot

- A cancel task during a timed-out preparation is written onto the row by the Store; the job now shows it too.
- Tests: preparation failure (spec regression round 7), and the start-not-saved marker keeping its slot.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Fix the outcome once a job starts ending before launch; save an unsaved reason before cancel task

- A context change at the launch check records stale, and a job that is ending before launch (cleanup, then the
  terminal write) refuses later stops, so shutdown or the budget cannot turn a stale or failed outcome into a requeue.
- cancelTask first saves an earlier unsaved first reason, so the Store's own cancelled write does not replace it.
  The save bumps the state version, so it runs only when the caller's version is current.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Start a job only after the caller's transaction ends; confirm reason writes; never free the slot before the marker

- Admission can be part of a userAction transaction. The job now starts after that transaction ends, and if it rolled
  back, the job gives back its reservation without preparing anything.
- A reason write that rolled back with its transaction now shows as unsaved, so the next cancel task saves it again.
- An unexpected failure sets its marker before the job is removed, so the slot is never free in between.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Undo an adopted cancel when the cancel task rolls back

cancelTask mirrors the Store's cancelled write onto a job that no longer takes stops. If the caller's transaction
rolls back, that reason is dropped again, so the attempt keeps its own outcome (for example the launch failure).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Show a Store-recorded cancel in status only, never as the job's reason

The adopted cancelled reason could reach the terminal write before the rollback check ran. It is now a status-only
flag; the terminal write reads the row's own reason, so a committed cancel task still wins and a rolled-back one
leaves the attempt's outcome alone at any microtask ordering.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Accept only this attempt's result; hold the slot while preparation files remain

- A settled result whose attempt ID or captured context is not this attempt's is never validated or saved; the
  attempt fails closed, as the question path does (Copilot review).
- A failed removal of host-side preparation files, before launch or after the terminal write, keeps the slot held
  under a preparation-not-removed marker until startup recovery removes the attempt directory (Copilot review).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

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

Author: mchwang