Resync the session when the app returns to the foreground

[PanAndDuck]

Summary

• Backgrounding the app suspends (and often kills) the live WebSocket, but nothing observed the scene returning to active, so a session left open during that time just sat frozen — the only way to see new content was to back all the way out to the list and re-enter, which tears down and rebuilds the whole screen via RootView's .id(...).
• SessionDetailView now watches scenePhase and calls a new refreshOnForeground() on a real background round-trip. A wasBackgrounded latch is used rather than comparing adjacent phases, since returning to the foreground reports .background → .inactive → .active, not a direct .background → .active.
• refreshOnForeground() branches on whether a turn was actually live:
  • If so, it reconnects the same liveTurn/connection in place (see "Related to fix(session): recover the live stream after a drop or backgrounding #10" below).
  • Otherwise it falls back to a full re-fetch (syncExisting, shared with the initial load()), so e.g. a rename or a message sent from another client while backgrounded is picked up too.

Related to #10

@Adam-Dalloul's #10 independently diagnosed the same root cause for the "turn was actively streaming" case — iOS suspends the socket without closing it, and the silent-reconnect backoff can't make progress while suspended — and fixed it more surgically (reconnect the same live turn in place, plus a real bug in consume's .snapshot handling that was dropping content produced during the outage). I've adapted that approach into this branch's resumeStreamAfterForeground()/consume() changes rather than duplicating it, with credit in the commit message. This PR's earlier commits also fix a case #10 doesn't cover (nothing was streaming, but the session changed elsewhere while backgrounded) and a duplicate-stuck-"in progress"-state bug that showed up while building the full-refetch fallback. Happy to drop the overlapping part of this PR if you'd rather land #10 as the canonical fix for the live-turn case — just say which shape you'd prefer.

Test plan

• Builds and runs on iOS Simulator
• Builds, installs, and runs on a physical device
• Backgrounding an idle session and returning re-syncs its content without needing to leave and re-enter
• Backgrounding mid-reply no longer leaves a stuck "in progress" placeholder alongside the (separately fetched) finished reply
• Reconnecting a still-streaming reply in place (the part adapted from fix(session): recover the live stream after a drop or backgrounding #10) — device test in progress

[Adam-Dalloul]

Keep it here, one PR beats two. I'll close #10 once this lands.

Could you put a trailer on that commit so the attribution sticks? Co-authored-by: Adam Dalloul <47503782+Adam-Dalloul@users.noreply.github.com>

One thing worth a look. Now that a live turn takes the resume path, discardStaleLiveState() can only fire on a turn that already ended locally: finalize, failLive and cancel all clear isTurnActive alongside isStreaming, so nothing streaming reaches that branch anymore. What does reach it is a failed or cancelled turn, and failLive keeps that one on screen on purpose, partial output plus the error. Backgrounding and coming back drops it, sendState = .idle takes the banner with it, and the error text is client side so the refetch can't restore it. Same for a reply that finished streaming but hasn't reconciled yet, which the send path guards with promoteUnreconciled. Probably either drop the discard or promote a non-empty turn first.