[kitlangton]

Closes #34918. Follow-up to #34917.

Allows API clients to attach durable, per-session context that rides the system context belief model.

What

• New session_context_entry table (session_id, key, JSON value; composite PK, cascade delete)
• SessionContextEntry service: list/put/remove plus load(sessionID), which emits one SystemContext source per entry keyed api/<key>
• loadSystemContext in the runner now takes the session ID and composes entries as the sixth producer
• New endpoints behind the session location middleware:
  • GET /api/session/:sessionID/context-entry — list
  • PUT /api/session/:sessionID/context-entry/:key — upsert { value: Json }
  • DELETE /api/session/:sessionID/context-entry/:key
• Client keys are slash-free ([a-z0-9][a-z0-9._-]*); the server derives the api/* SystemContext namespace by construction, keeping core/* reserved for built-ins
• Regenerated packages/client and plugin effect API surfaces

Rendering

Server-owned phrasing, no client-supplied text. String values render verbatim inside a <context key="..."> block (the common case: prose instructions); other JSON pretty-prints. Because entries flow through the reconcile/checkpoint lifecycle:

• PUT a changed value → chronological System update at the next turn boundary
• DELETE → removal announcement via the stored removal text
• Compaction folds accumulated updates into the rebaselined system prompt
• Forks inherit applied state via the copied checkpoint

Testing

• Belief-lifecycle test in session-runner.test.ts: baseline render, update narration, removal announcement, list/remove semantics
• End-to-end put/list/remove roundtrip plus 404 coverage through the real router in the sdk-next embedded test
• Full core suite green (watcher flakes aside); repo-wide typecheck clean; migration --check fresh