fix(drivers): auto-dismiss DriverDetailSheet when driver disappears

[variablefate]

Summary

Fixes #62. After PR #61 migrated DriverDetailSheet from let driver: FollowedDriver (with appState.getDriver(pubkey:) ?? driver fallback) to let pubkey: String consuming an Optional DriverDetailViewState, the sheet lost its stable fallback snapshot. When the backing driver was removed out-of-band — background Kind 30011 sync, logout from another session, account-deletion teardown — state went nil and every state?.foo read in the body short-circuited, leaving every section blank except the hardcoded pubkey. Note edits silently no-op'd against the missing driver.

Design choice

Option 2 from the issue (auto-dismiss) — endorsed by the issue body: "the sheet has no purpose without the backing driver and a silent close matches what the user gets when they delete the driver themselves."

• Option 1 (snapshot fallback) rejected: keeps a stale view of a driver that no longer exists in any repo, and removeDriver/note edits would still silently no-op against the ghost — worse than the existing pre-feat(views): wire views through presentation types #61 behavior in subtle ways.
• Option 3 ("Driver removed" placeholder) rejected: extra UI surface for a path that's already rare; "their detail sheet vanished" matches the user's mental model of "the driver no longer exists."

What changed

DriverDetailSheet.swift — added .onChange(of: state == nil, initial: true) that calls dismiss() when the lookup transitions to nil. initial: true also handles the (currently unreachable but cheap to guard) case of opening the sheet for a pubkey that's already gone.

Test approach

UI-layer auto-dismiss behavior is hard to assert directly in a unit test. Instead I added a regression test in AppStatePresentationTests.swift — AppStateDriverDetailViewStateTests.returnsNilAfterDriverRemoved() — that pins the contract the auto-dismiss depends on: removing a driver from FollowedDriversRepository flips appState.driverDetailViewState(pubkey:) from non-nil to nil. If that contract ever regresses, the auto-dismiss silently stops firing.

Verification

xcodebuild test -project RoadFlare.xcodeproj -scheme RoadFlare \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' \
  -only-testing:RoadFlareTests/AppStateDriverDetailViewStateTests

→ TEST SUCCEEDED (5/5 passed, including new returnsNilAfterDriverRemoved)

Full project compiles clean (RoadFlare app + RoadFlareCore + RoadFlareTests + RoadFlareUITests targets).

Test plan

• Open DriverDetailSheet for a followed driver
• Trigger out-of-band removal (e.g. simulate background sync dropping the driver, or remove from another session)
• Sheet auto-dismisses silently — no blank-state flash, no orphaned UI

🤖 Generated with Claude Code

[variablefate]

Code review — First pass

No actionable findings. Five parallel reviewers (CLAUDE.md compliance, shallow bug scan, git history, prior PR comments, code-comment compliance) surfaced three candidates; all verified as either false positives or intentional. Notes for posterity:

1. Capture-once pattern (PR feat(views): wire views through presentation types #61): The body caches state once to avoid 6 lock acquisitions × 13 reads of appState.driverDetailViewState(pubkey:). The new .onChange(of: state == nil, initial: true) reads the captured state local — Swift evaluates the of: argument eagerly at body-evaluation time, so this does not add a 14th repo lookup. Cached pattern preserved.

2. Explicit dismiss() after removeDriver() is not dead code. The "Remove Driver" button's local dismiss() runs synchronously for snappy UX; the new .onChange is the safety net for out-of-band removals (background sync, another-session logout). They're complementary, not redundant.

3. .onAppear re-fetches state, but .onChange uses the captured local — by design. .onAppear runs after body settles so the captured local can be stale; .onChange(of:) is wired to the cached value and re-fires on body re-evaluation. Correct SwiftUI semantics for each.

🤖 Generated with Claude Code

_{If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[variablefate]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[variablefate]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{If this code review was useful, please react with 👍. Otherwise, react with 👎.}