P4.1 long-term memory: caller identity resolves to run/session, not subject — memory can't be shared across sessions

Summary

P4.1 ("MicroVM egress transport", docs/p4-1-egress-transport branch — not yet merged; the design that filed #267) makes long-term agent memory reachable from a microVM guest as just another allowlisted destination behind the shared egress proxy (§2, §6): no mount, no new wire field, reached exactly like a git push or a GitHub API call. But the only caller-identity mechanism it defines (T4, §5) is the jail socket path — stable across one run's VM churn (P4 §5.3), but scoped to run/session, not to any human/tenant identity. If a memory store's credential — or its "which memory" scoping — is resolved from that identity, two different sessions belonging to the same user are indistinguishable from two unrelated callers, and memory can't actually be shared across sessions. That defeats the point of a store meant to be long-term.

Why this is likely already the intended next step, per P4.1 itself

• P4.1 §5: "Z1 keeps the question... does not claim jail-path identity generalises" — T4 is explicitly scoped as a tier-local stopgap for authenticating a sandboxed call, not a statement about who the call is on behalf of.
• MU1 already has the identity axis that fits: a session token "carries subject and session" (docs/specs/2026-09-08-multi-user-control-plane-design.md:44) — subject is a human/tenant identity, independent of and stable across many sessions.
• The model's own per-turn credential already resolves this way — run-turn.ts's UpstreamCredential, "the per-request credential the control plane resolved for THIS turn's subject" — the memory store just isn't wired into that same resolution path yet.

What closing it involves (not decided here)

1. Add the memory store as a sandbox-egress credential consumer (packages/control-plane/src/credential-store.ts:13) keyed by subject, the same shape as the existing model-inference consumer.
2. Confirm/require the proxy's placeholder-swap (Z5 §4.3, P4.1 T5) resolves using token.sub, not anything derived from T4's jail-socket identity — T4 authenticates "this is a legitimate sandbox call"; subject decides "whose memory."
3. Decide whether "which memory" is a data-plane parameter the agent's tool call supplies (a namespace/user argument the model can see and set) or is inferred entirely server-side from subject with no guest input at all — a real design choice with different exposure either way.

Relationship to other issues

• Depends on / extends P4.1 (docs/p4-1-egress-transport, commit 453c45d — not yet on main).
• Adjacent to #267 (working-memory/session-scoping) and #239 (P5 session identity isolation), but distinct: this is about the subject identity for long-term memory, not workspace lifetime or request auth.

Start with docs/p4-1-egress-transport, MU1's multi-user control-plane design, packages/control-plane/src/credential-store.ts, and run-turn.ts. Trace how the sandbox-egress consumer and P4.1 placeholder swap identify a caller, then resolve the subject-based credential path and the decision about whether memory scoping is supplied by the guest or inferred server-side. Done means the design is settled and consistent with subject identity across sessions.