feat(app): make tabs generic and composable

Problem

Top-level app tabs currently have a closed data model: a tab is either a session or a new-session draft, and the shell derives its URL and content from that built-in type. This makes tabs difficult to reuse for other app views and prevents plugins from contributing views that participate in the same lifecycle.

Tabs should be a generic shell primitive rather than a special case for sessions.

Direction

Introduce a registry of tab/view types owned by the app shell. A registered type should define the behavior needed for the shell to host it, such as:

• stable identity and persistence/serialization
• URL/deep-link mapping
• title, icon, and other presentation metadata
• content renderer
• lifecycle capabilities such as close, restore, and reorder

Core app features and plugins should use the same registration surface. Routes may open or select a registered view, while routing mirrors the active tab; individual routes should not each implement their own tab semantics.

The same view abstraction should also be composable into a future split-pane layout, without requiring split behavior in the first implementation.

Initial scope

• Generalize the existing session/draft tab union without regressing current tab persistence, switching, closing, reopening, or cross-server behavior.
• Support built-in non-session views through the generic mechanism.
• Define how plugins register a tab-capable view.
• Keep the default tab UI simple; horizontal and vertical presentations should consume the same model.
• Preserve deep links: navigating to a registered view should open or select the corresponding tab predictably.

Non-goals

• Building a full docking/window manager in the first pass.
• Allowing every route to invent bespoke tab lifecycle behavior.
• Shipping split panes as part of the initial generalization.