Support session visibility independently of parentage #39911

Problem

Some integrations create durable internal sessions that need normal execution, persistence, API access, logs, and debugging, but should not appear in user-facing session pickers or recent-session history by default.

Today an integration can avoid opening a TUI tab, but the resulting top-level session still appears in global session discovery. Using parentID to hide it would conflate two independent dimensions:

• Parentage describes structural or conversational ownership between sessions.
• Visibility describes whether a session is presented in ordinary user-facing discovery UI.

A background controller may be top-level but hidden. A child session may still be intentionally visible. These combinations should remain representable.

Desired behavior

• Session creation can explicitly mark a session as hidden/internal without assigning a parent.
• Hidden sessions remain addressable by ID through the API and available to logs, traces, and debugging tools.
• Ordinary session pickers and recent-session lists exclude hidden sessions by default.
• Administrative/debug discovery can include hidden sessions explicitly.
• Opening a hidden session directly by ID remains possible.
• Visibility does not change execution, persistence, deletion, or parent/child semantics.

API shape to explore

This needs design rather than assuming a final field name. One possible direction is a persisted session presentation/visibility value plus an includeHidden session-list filter. The durable representation should avoid deriving visibility from title, agent, or parentID.

Motivation

OpenCode Voice uses a durable controller session so delegated actions remain observable and debuggable. It can keep that session out of the tab strip, but cannot currently keep the active internal controller out of the session picker without deleting it or misrepresenting it as a child session.