[FEATURE]: TUI plugin API: projected-session prompt hooks and session notice slot #27813

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Related to #26097, but focused specifically on the prompt/session-area surface rather than session projection or session-list policy.

Summary

I'd like to propose a small extension to the TUI plugin API so plugins can influence prompt behavior for projected/logical sessions and render a lightweight native session notice above the prompt.
This is not a request to upstream a specific background-task product feature.
The goal is to expose generic host hooks so advanced plugins can keep using the native prompt/session UI while reducing local host patching.

Problem

Today, even with session/session-list projection hooks, some advanced addons still need a few additional host hooks around the native prompt area.
In practice, projected/logical session models may need to express things like:

• whether prompt submission should still be allowed while the underlying concrete session is busy
• whether prompt submission should be intercepted and rerouted to a custom submit path
• whether the current session should display a small host-rendered notice above the prompt
  Without these hooks, the remaining alternatives are:
• replacing the native prompt with custom UI
• fragile command-level workarounds
• or local host patches

Proposal

Add a small set of optional prompt/notice hooks with full native fallback.

1. Prompt busy override

Conceptually similar to:

• allowSubmitWhenBusy?: boolean
  This would let a plugin indicate that the native prompt should remain usable even if the underlying concrete session is currently busy.
  Important:
• default behavior stays unchanged
• this is opt-in
• core still owns the native prompt UI
• plugin only provides policy

2. Prompt submit interception

Conceptually similar to:

• submit?: (input) => boolean | void | Promise<boolean | void>
  This would let a plugin intercept prompt submission before the native submit path runs.
  Example responsibilities:
• reroute submission to a different target session
• use an alternate async submission path
• attach additional metadata or prompt parts
• return "handled" so native submit is skipped
  Important:
• default native submit behavior remains unchanged
• this is opt-in
• plugin does not need to replace the native prompt

3. Session notice slot

Conceptually similar to:

• session_notice
  This would let a plugin render a small host-rendered notice above the native prompt/session footer area.
  Example use cases:
• projected/inspection session banners
• lightweight status or guidance text
• contextual foreground/background hints
  Important:
• this is just a generic render surface
• no feature-specific behavior needs to live in core
• default rendering remains unchanged when unused

Why this should live in core

This is not feature-specific logic.
It is host-level TUI extensibility around the native prompt/session area.
These hooks would help any plugin/addon that needs a logical session model on top of the native TUI, while preserving:

• native prompt/session rendering
• native fallback behavior
• no runtime/server changes

Why this matters for plugin-only addons

Some advanced addons can already work with local TUI host patches, but they cannot yet ship as clean plugin-only integrations against official OpenCode builds.
A successful upstream API here would allow that class of addons to:

• keep using the native prompt/session UI
• materially reduce local prompt/session-area patching
• avoid reimplementing the prompt just to change session-routing behavior
• evolve as plugins/addons instead of forks

Success criteria

A successful outcome would be:

• advanced plugins can keep the native prompt/session UI while customizing projected-session behavior
• no default UX regressions
• no feature-specific logic needs to live in core
• local host patch surface is materially reduced for this class of addons

Open question

Would maintainers prefer:

1. discussing this prompt/notice API shape first in an issue, then opening small PRs
2. or going directly to a focused PR for one hook at a time?