Multi-tab core: switching tabs preserves page state and BLE connections

[davertay-j]

Parent

Sub-issue of #287 (multi-tab support implementation plan).

What to build

The headline feature of #283. Open site A, open site B from the tab grid, then switch back to A: A renders instantly with its prior DOM/scroll/JS state — no reload — and any BLE connection A held is still connected, with GATT notifications received while A was backgrounded reflected in its page state.

Under the hood: tabs become retained sessions governed by the LRU cache (cap 4, active pinned). All live web views remain attached to the view hierarchy (invisible and non-interactive when not active) so their content processes keep running; browser chrome (nav bar, sheets, alerts) mounts only for the active tab. The tab grid keeps sessions alive. Opening a tab beyond the cap tears down the least-recently-used background tab, which quietly reverts to reload-on-revisit. A freshly opened empty tab (no page load yet) occupies no cache slot and gets no grid cell, as today.

Acceptance criteria

• Switch A → grid → B → grid → A: no reload, page state intact (verify with a scrolled page and a form field)
• BLE connection established in A survives the round-trip through B; notifications delivered while A was backgrounded appear in A's page
• Only the active tab shows chrome; background tabs never present sheets or alerts
• Opening a 5th tab evicts the least-recently-used background tab (its BLE disconnects); revisiting it reloads the URL
• The active tab is never evicted; visiting the grid does not tear down any session
• Fresh empty tabs take no cache slot and appear in the grid only after their first page load (as today)
• App launch restores the last-opened tab exactly as today; CI green

Blocked by

• Prefactor: session-scoped web view lifecycle (no behavior change) #288 (Prefactor: session-scoped web view lifecycle)
• Tab session cache: LRU policy component with unit tests #289 (Tab session cache: LRU policy component)