feat(coding-agent): allow extensions to append to the session system prompt

[wutongyuonce]

Closes #9432

Summary

• allow session_start handlers to return append-only systemPromptAppend contributions
• collect contributions in extension/handler order with trimming, source metadata, and existing error isolation
• fold the session snapshot into the base prompt across startup, session replacement, reload, tool changes, and resource discovery
• expose the new result and contribution types and document lifecycle, ordering, caching, and before_agent_start interaction

Testing

• npm run check
• focused coding-agent coverage: 4 files, 89 tests passed
• ./test.sh: the first run reached 2240 coding-agent passes; after dependency hydration, the remaining 3 focused failures require the missing local packages/chord/dist build artifact
• GitHub Actions build-check-test
• reviewed in a separate gpt-5.6-luna session; one type issue was fixed and the re-review found no remaining actionable findings

AI-assisted disclosure: this PR was prepared with AI assistance and reviewed against Issue #9432, the linked design, and the affected source paths.

[gaoanze888]

Reviewed exact head c113a83 against current main. The new session_start result is append-only, collected sequentially in extension/handler order with existing error isolation, and every handler sees the same contribution-free base prompt. The snapshot is rebuilt for startup/new/resume/fork/reload, preserved across tool/resource rebuilds, and is not persisted. Prompt ordering is consistent in both default and custom branches, and the explicit _extensionsBound flag correctly handles empty bindings without opting unbound SDK sessions into lifecycle events. Public types/exports and documentation are aligned. The standalone system-prompt suite passes 16/16 locally; the remaining focused suites are blocked locally by generated package artifacts, while exact-head GitHub build-check-test is green. No blocker found.

[wutongyuonce]

Hi @mitsuhiko @badlogic — gentle bump. This PR is still open and mergeable. Happy to adjust anything once you have a chance to look. Thanks!

[mitsuhiko]

Given the changes we landed now to sections in system prompts I would like to understand if the new system we have in place is not making this PR obsolete?

[wutongyuonce]

@mitsuhiko you're right — this looks obsolete given the new system.

The sections + mid-conversation system message design covers what I was trying to do here, and in a better way. The original problem was stable extension instructions having to live in a per-run before_agent_start rewrite of the whole system prompt, which made the cache prefix depend on a hook that replaced _baseSystemPrompt every turn.

Declaring the desired composition via systemPromptOptions.sections (and diffing it) is the same goal with a sounder model: unchanged sections keep the prefix, and real changes become a named patch instead of replacing the blob.