feat(playbooks): persist deterministic runs and explicit recovery

[BastiHu]

Playbook execution needs durable state and predictable behavior across retries and restarts.

Add the event-backed run store, pure transitions, typed contracts, migrations, and worker reconciliation. Preserve completed evidence and require explicit recovery of interrupted work.

Stack 2/9. Depends on #156. Merge in order, retargeting to j5/main as predecessors land. Full-stack testing branch: codex/playbooks-09-aurora-loops.

Validation at the integrated stack tip: 179 server/shared tests and 104 web tests passed; server and web typechecks passed. Each regenerated runtime manifest was checked. The adapter slice independently passed 92 tests, including the parser regressions.

Model: GPT-5 · Harness: Codex

[Jacksondr5]

Naming: "run" already means something else upstream, so a playbook instance needs a different noun.

Upstream uses "run" for one execution of a turn inside a thread: OrchestrationV2Run, RunId, ids of the form run:thread:…:ordinal:N, and the orchestration_v2_projection_runs table. This stack introduces a second, unrelated "run" for a playbook instance: the Run contract in packages/j5-playbook-contracts, the j5_playbook_runs and j5_playbook_* tables with run_id columns, playbook:<hash> ids, the /runs route, and UI copy such as "Run details" and "Active runs".

Two meanings of a core word in one server is a reading tax on every file that touches both, and the tables and ids are the part that gets expensive to rename after data exists. Please pick another noun for a playbook instance and apply it to the contract type, tables, ids, route and copy in one pass. The UI already leans toward just "playbook" ("1 playbook", "No playbooks in this scope"), so that or "execution" would both read fine; Jackson's call.

Filed from the stack review by Claude Fable 5.1 (Claude Code).

[Jacksondr5]

Heads-up: this PR touches Squadron code that is being removed.

What changed on j5/main (2026-10-08). J5 is retiring Squadrons and folding their behavior into projects (#412, decided 2026-10-05). The client half has merged (#454, #455, #456):

• The Squadron picker, draft chip, sidebar Squadron filter, first-run gate and the Create, Rename and Delete Squadron dialogs are gone. Most of apps/web/src/j5/squadron/ is deleted.
• New threads, drafts, the sidebar filter and Add Project use upstream's project flow again.
• The Fleet page, Inbox and thread cards read the thread's project.

Still to come. The server migration re-keys the ledger from Squadrons to projects, removes list_squadrons and join_squadron, and renames squadron_id / squadronId to project fields across the server, the shared contracts and the peer protocol. After that, a rename pass removes the word from the remaining code.

For this PR. It uses Squadron ids in about 16 changed lines in apps/server/src/j5/playbook/Store.ts and Migrations.ts, and in packages/j5-playbook-contracts/src/ (index.ts, sidebar.ts, observability.ts).

When you next rebase: use the thread's or workspace's projectId where this uses a Squadron, in stored rows, contracts and queries alike. No Squadron needs to be chosen or sent when a thread is launched; the server derives the home from the project. The smaller PRs in this stack (#163, #159, #143, #164) have one to four such lines each and need the same change.

Posted by an AI agent on Jackson's behalf.