Protocol connections own ordered delivery and teardown

[jsmestad]

Type: Feature

What

Each macOS protocol connection should have one owner for ordered delivery, replacement, and teardown. Initial startup and reconnect currently assemble the same resources independently inside AppDelegate.

Why

The reader, encoder, capacity-one handoff, and delivery task have one lifetime but are coordinated through separate optional fields. Consolidating their ownership removes repeated setup and makes cancellation order explicit.

Acceptance Criteria

1. Initial startup and reconnect use the same connection lifecycle, with exactly one active delivery consumer for the current connection. ✅ PR #3392
2. Frames and decode failures preserve their current order and capacity-one admission behavior; reconnect does not create an unbounded queue or a task per message. ✅ PR #3392
3. Replacing or stopping a connection cancels its admission and consumer before new delivery starts. A delayed callback from the retired connection cannot disconnect the replacement encoder. ✅ PR #3392
4. Stop is idempotent, wakes a producer waiting for admission, and does not block the main actor waiting for a pipe read to finish. ✅ PR #3392
5. Development-mode disconnect and bundled-process restart retain their existing application behavior, generation/recovery policy, and frontend-owned resize contract. ✅ PR #3392
6. Focused lifecycle tests demonstrate startup, delivery, replacement, delayed old callbacks, and teardown without duplicating connection assembly in application code. ✅ PR #3392