feat(core): API-managed per-session context entries #34918

Follow-up to #34917.

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

Design (settled during the context checkpoint work)

• New table: session_context_entry (session_id, key, value) — durable, session-scoped, JSON-valued
• A seventh context producer (ApiContext.load(sessionID)) reads the rows and emits one SystemContext source per entry with generic renderers around the JSON value
• Key namespace split enforced by construction: core/* reserved for built-ins, api/* for user entries (the SystemContext.Key pattern already requires namespace/name)
• API surface: put/delete a value per key (shape TBD alongside the Protocol/Server HttpApi work; requires client regen)

What falls out for free

Because entries flow through the existing reconcile/checkpoint lifecycle:

• PUT a changed value → next turn renders a delta update message
• DELETE → removal announcement via the stored removal text
• Compaction folds accumulated updates into the rebaselined system prompt
• Forks inherit entries' applied state via the copied checkpoint; move/revert reset behaves like every other source

Notes

• loadSystemContext in session/runner/llm.ts needs a sessionID parameter alongside agent (the runner already has it)
• Generic rendering for arbitrary JSON values needs a small design pass (baseline/update/removed phrasing)