S133 — Running sessions pick up new content

[The-Running-Dev]

What

Running sessions move onto newly published content at createSession, submitAction and resumeSession (16 §5.2, §5.3; 20-contract §7, C25). SessionHost gains the contracted content?: ContentChannel. getStrings now returns the union of a session's live epochs (C27, 16 §5.7).

• createSession asks the channel once and starts the game on its answer. No content entry is written.
• submitAction adopts after an accepted action commits, in the action's own write. Messages come from the old epoch and the scene from the new one.
• resumeSession writes an adoption at revision + 1. If that write fails, the store restores the record and returns the unadopted scene. A conflict also evicts the cached record.
• A refusal, an offer the archive does not hold, or a throwing channel never fails a command.
• Queries, previewAction and rejected actions never consult the channel.

Criteria

• S133.1 — met: S133.1 — createSession starts on the channel's version (3 tests: scope and single call, no-offer/throw fallback, anonymous scope)
• S133.2 — met: S133.2 — an accepted action adopts after it commits, in its own write (one write at revision 1, log [action, content], messages message.v1 / scene scene.v2; profile fold sees the action's epoch)
• S133.3 — met: S133.3 — resumeSession adopts in its own write (revision + 1 write; no write on the same version; storage_failure and concurrent_modification each restore, serve the v1 scene, and adopt at the next resume)
• S133.4 — met: S133.4 — a refusal or a failing channel never fails the command (refusal at submit and resume, core.content.pinned emitted, unheld offer, throwing channel)
• S133.5 — met: S133.5 — queries, previews and rejected actions never consult the channel (zero recorded calls across getScene, getView, getStrings, listCampaigns, listSaves, previewAction, and a rejected submitAction). All 120 existing session tests pass unchanged with no channel.
• S133.6 — met: S133.6 — getStrings spans every live epoch (never-adopted session gets exactly v1's table and a v2-created one exactly v2's; after adoption a dropped key resolves, a shared key is the newer text, and both halves of the adopting result resolve; a migration entry starts the union at its to)

Differs from design

Nothing differs from the contract. The judgement calls are recorded in 90-decisions.md, 2026-10-09:

• An offer at createSession that names an unheld version fails with unknown_campaign. The kind and profile data come from the offered epoch.
• The profile fold receives the campaign of the epoch the action resolved on, not the registry's.
• A failed resume adoption write restores the record, and a conflict also evicts it. core.content.adopted has already been emitted by then, so an event stream can show an adoption that did not persist.
• getStrings skips an epoch the archive no longer resolves.

Verified

• npm run typecheck, npm run lint: clean.
• npm test: 119 files, 2318 tests passed. The first full run had one failure: long-horizon.replay.test.ts "long-horizon-win: every state it reaches round-trips" ran past 10 s under load. It passed alone (23/23) and on a second full run. This is a pre-existing timing flake, not this change.
• ./build/Test-Documentation.ps1: passed (19 generated pages, 135 Markdown files).
• git diff --check: clean.
• ./docs.ps1 -BuildOnly was not run: it is not installed locally. CI's Verify Documentation Build covers it.

Revert verification. Each fix was reverted alone and store.test.ts was run:

Reverted	Failing tests
submitAction adoption	4
resumeSession adoption	4
resumeSession restore on failed write	1
resumeSession eviction on conflict	1
channel try/catch	2
createSession passes the offered version	3
profile fold uses the action's epoch	1
liveEpochs starts at the last migration	1
getStrings union (current epoch only)	1