v0.9.14: App-server session notice surface and running-work accounting for background-capable clients

## Why this matters

GPUI Hmbown/codewhale-apps#573 (Linear APPS-47) owns window close, app quit, notifications and background work. Two of its requirements are Engine facts the desktop cannot derive today:

- "Multiple threads may continue while the user switches tasks… Quit must account for every running owned thread, not only the visible one" — needs a served accounting of in-flight work.
- Notice kinds `subagent-terminal`, `elevation-needed`, `model-notify` exist as notification events (`crates/config/src/notifications.rs`) but no snapshot or event field carries them to a watch-only client, so the desktop can only ever surface a subset of what the TUI shows.

## Current behavior

- The snapshot carries turn status per thread, but there is no aggregate "running owned work" view; a client must enumerate threads and infer.
- `subagent-terminal`, `elevation-needed`, `model-notify` are declared notification events (schema `notifications.event_sound.events` validator set) with no client-readable emission surface — no notice kinds in `runtime_api.rs`.
- `/v1/threads/{id}/notifications/prepare` (`notification_delivery::prepare`) serves OS-notification payload prep, not these notice kinds.

## Desired behavior

1. A served set of active notices per thread (or aggregate) covering at least `subagent-terminal`, `elevation-needed`, `model-notify`, each with thread/turn identity so a client can target the right task.
2. A running-work accounting — threads with in-flight or queued turns — so quit/background decisions enumerate owned work without guessing.
3. Delivered through the snapshot or the event projection (#6152), whichever lands first; clients stay read-only projections.

## Acceptance criteria

- [ ] A watch-only client can observe each listed notice kind with thread/turn identity
- [ ] A client can enumerate all owned threads with running or queued work in one call or one snapshot field
- [ ] Notices clear when the underlying condition settles — no stale banner after the event resolves
- [ ] `cargo test -p codewhale-tui` covers emission and clearing for at least one kind end to end

Related: Hmbown/codewhale-apps#573, #6152 (event projection), #6169 (TUI job-control handshake), #5581 (event-granularity audit).

Start with crates/config/src/notifications.rs and runtime_api.rs, then inspect the snapshot or event projection referenced by #6152 and the /v1/threads/{id}/notifications/prepare entry point. Trace how notice events and running turns are currently exposed, then run cargo test -p codewhale-tui. Done means watch-only clients can identify the listed notices and all running or queued owned threads, with notices clearing when conditions settle.

Written by the indexing model from the issue text.