[2.0] Add session-scoped keyed context contributions #34380

Problem

Embedders need a way to attach app-owned context to an OpenCode session that is neither global agent identity nor ordinary user transcript text.

Current nearby primitives do not fit well:

• agent.system is agent/profile-scoped and static for the selected agent.
• User prompt text is turn-scoped transcript content and can be buried or compacted away.
• A per-prompt system override is too ad hoc for durable session facts and makes ordering / compaction semantics unclear.

This came up while building an embedded chat agent for Discord/Slack: provider flavor can be handled by provider-specific agents, but session facts still need a durable, refreshable place.

cc @kitlangton

Examples of session-scoped context

• Channel/thread metadata: provider, channel name, thread title, participants, URLs.
• App-owned product state: case/project/task state, customer/account facts, current incident status.
• Conversation policy: response formatting, notification rules, transport-specific affordances.
• Tool/runtime facts that should be refreshed over time and survive compaction.

Desired primitive

A session-scoped context API with keyed contributions, roughly:

• Add or replace a contribution by key for a session.
• Remove a contribution by key.
• List/read active contributions for debugging/projection.
• Each contribution has an owner/key, content, and possibly ordering/priority metadata.
• Contributions are projected into model context separately from user/assistant transcript messages.

The key property is replacement semantics: an embedder should be able to update channel.metadata or case.state without appending another pseudo-message to history.

Compaction semantics

The context should survive transcript compaction and continue to be included after compaction as current session context, not historical user text.

Open questions:

• Are keyed contributions persisted as part of session state?
• How are they ordered relative to agent system text, tool instructions, and compaction baselines?
• Should compaction snapshots include rendered contributions, references to current keys, or both?
• How does prompt caching interact with frequently changing contributions?
• Do plugins/apps own a key namespace to avoid collisions?

Why this matters for 2.0

This gives embedders a clean session-level boundary for durable context without abusing prompt text or per-turn system overrides. It also keeps static agent identity, mutable app facts, and transcript history as separate concepts.