P4 microVM tier: working memory cannot span a session's turns (workspace is keyed per run)

Summary

On the P4 microVM sandbox tier, an agent's short-term (working) memory cannot span a session's
turns, because the tier's isolation unit is the run, not the session. Long-term memory is
unaffected — P4.1 routes it to an external store over the egress proxy — but working memory has no
home on this tier today.

Why

Standard agent-memory decomposition puts working memory as volatile per-session state that is
cleared when the session ends, and long-term memory in an external database / vector store / graph
that persists across sessions. The tier serves neither shape cleanly:

So a session's working set dies at run boundaries, and anything that deliberately crossed a run
boundary would be crossing the exact line §8 asserts nothing crosses.

How P4 currently avoids the problem

P4 §9 keeps interactive /turn on the container tier entirely: "It never leases
(run-turn.ts:57), so it has no run id to populate workspace_key with, and §3.4 refuses an empty
one on the VM path rather than letting it mean 'share one workspace'."

That is a legitimate deferral, but it means the microVM tier as designed and as measured (E10,
E11) cannot host a multi-turn interactive session at all. The gap is not a bug in the tier; it is
an unclaimed scope boundary that will block the tier from serving interactive work.

What closing it involves

Not decided here — this issue exists to make the decision explicit rather than implicit:

1. A session-scoped key alongside the run-scoped one. Spends the "one wire change" budget P4 §3.4
   sets and P4 §9 is already guarding for Release{workspace_key}, and requires restating §8's gate
   as "no bleed between sessions" plus a new test for the positive half (two runs of the same
   session do share, two runs of different sessions do not). Nothing tests that today, because
   nothing was supposed to be shared.
2. Give /turn a request-scoped key. P4 §9 notes this is "the same plumbing the next multi-user
   slice (MU1 is #238) owes it for pool selection" — so it may be cheaper as MU-track work than as
   P-track work.
3. Accept the boundary. Interactive sessions stay on the container tier permanently, and the
   microVM tier serves only run-to-completion work. Cheapest, and possibly correct — but it should
   be a recorded decision, not a side effect.

The ext4 constraint matters for option 1: P4 §4.3 establishes that only one VM may hold a
workspace_key's rw mount, so a session that fans out concurrent leaf runs would contend. Whether
a session ever does that is an open product question and is worth settling before designing.

Relationship to P4.1

P4.1 — MicroVM egress transport
§3 marks this explicitly out of scope, and resolves the long-term memory half by making it an
allowlisted destination behind the egress proxy (no mount, no new key, no wire change). This issue
is the remaining half.

Start with the cited P4 sections, harness/src/sandbox-lease.ts, and run-turn.ts to understand the run-scoped workspace and the current interactive-session boundary. Compare the three proposed directions, including the ext4 concurrency constraint and P4.1's scope, then record the decision and its implications. If session sharing is chosen, completion includes updated key/release semantics and tests for sharing within a session and isolation between sessions.