fix(rpc): enforce durable_session_id on the worker session registry and write a chosen id to disk at open

[code-yeongyu]

What

Completes the open_session.durableSessionId contract from #1956 on the registry the multi-session host actually runs, and makes a caller-chosen id durable from the moment of open.

Fixes #2010

How this was found

Not by a unit test. The registry-level suite from #1956 was green. I drove the REAL senpi --mode rpc --multi-session process over its stdio protocol with a new scenario script (.agents/skills/senpi-qa/scripts/scenarios/durable-session-id-qa.mjs, zero model tokens) and it scored 6/8:

[FAIL] duplicate live id -> session_id_in_use — undefined   (open returned success:true)
[FAIL] reopen reads the chosen id back — 01a0c984-…         (a fresh uuidv7; the file never existed)

Root causes

1. The guard was on the wrong registry. multi-session-host.ts:163-171 instantiates WorkerSessionRegistry whenever a worker configuration is present — the real host's normal shape. #1956 added the duplicate-live-id scan only to RpcSessionRegistry.openSession. WorkerSessionRegistry.openSession forwarded the profile straight to worker.prepare, so two live sessions could share one durable id. The malformed-id refusal did fire on the real host, but only as open_failed: invalid_session_id from the worker's own SessionManager after the worker had already died.

2. A caller-chosen id was not on disk until the first assistant message. SessionManager._persist defers creating the file — correct for a host-minted id that nothing references yet, wrong for an id the caller already holds in its own records. Create → close before the first reply → reopen the same path minted a different identity.

Fixes

• worker-session-registry.ts: openSession validates the id with assertValidSessionId (→ invalid_session_id) and refuses an id any non-closed entry holds (→ session_id_in_use), both synchronously before its first await, mirroring RpcSessionRegistry. The requested id is recorded on the entry before that await so a concurrent open sees it; snapshot.state.sessionId still overwrites it after commit (so a resume keeps its header id). Re-opening the same path stays an attach.
• session-manager.ts: when NewSessionOptions.id is present on a not-yet-existing path, the header is written at open.

Evidence

RED first — new test/suite/rpc-worker-durable-session-id.test.ts against the real worker registry (real Worker threads, production routing), 3 cases, 3 failed before the change:

AssertionError: promise resolved "{ sessionId: 'rpc-2', …(2) }" instead of rejecting
AssertionError: expected Error: invalid_session_id to match object { code: 'invalid_session_id' }
AssertionError: expected false to be true   (existsSync(sessionPath))

After:

gate	result
rpc-worker-durable-session-id.test.ts (real workers)	3/3
real-surface scenario (real senpi process over stdio)	9/9, including "chosen id is in the JSONL header on disk"
rpc-open-session-durable-id + rpc-open-session-resume + rpc-worker-capacity + rpc-worker-routing + rpc-retain-on-disconnect + rpc-close-ordering	39/39
pgrep -f rpc-host-fixture.mjs | wc -l after the run	0
changelog gate	PASS

Lesson recorded

When a contract lives behind an interface with two implementations, the invariant goes on both — and only a real-process scenario proves which one actually runs. The scenario script stays in the repo so the two registries cannot drift again.

---

Summary by cubic

Fixes the durable session id contract on WorkerSessionRegistry, the registry the real multi-session host runs, so the duplicate-live-id and malformed-id guards apply there too. A caller-chosen id is now written to disk at open, so create → close → reopen keeps the same identity.

Bug Fixes

• WorkerSessionRegistry.openSession refuses a duplicate live id with session_id_in_use and a malformed id with invalid_session_id, synchronously before spawning a worker, mirroring RpcSessionRegistry.
• A caller-chosen id previously left no file until the first assistant message; the header is now written at open.
• Adds a real-process scenario over stdio and a Worker-backed test suite so the two registries cannot drift again, and records the fixes in the changelog under [Unreleased].

^{Written for commit d178a50. Summary will update on new commits.}

[code-yeongyu]

Rebased onto main (610d70af8f, 14 commits) — re-verified on the new head

The previous head (a3f30c35cb) conflicted with main in src/core/changes.md (the #1989 rename entries landed above mine), which is why no test workflow dispatched for it — only the label/security checks registered. Rebased; the only conflict was that tracker, resolved as a union with every entry preserved and git diff --check clean.

One trap worth recording: immediately after the rebase the real-worker tests went red with session_closing. The worker's quarantine line named the real cause — does not provide an export named 'readByProviderId' — main had added an export to packages/ai and the workers load dist, which predated the rebase. A rebuild, not a code change, fixed it.

On the rebased head (d8941cfe95):

gate	result
rpc-worker-durable-session-id + rpc-open-session-durable-id + rpc-open-session-resume + rpc-worker-routing	31/31
real-surface scenario (real senpi --mode rpc --multi-session over stdio)	9/9
pgrep -f rpc-host-fixture.mjs after	0
changelog gate vs new base	PASS

The earlier relocated-worker (windows-latest) failure was rmSync EBUSY on a compile-fixture temp dir in a test that never touches session code; its rerun passed, and every other recent run of that job is green — a Windows teardown flake, not this change.