Optional floating Coach button — pin to a corner or lock it #491

The problem

Coach is currently reachable only through More → Coach. That's fine when you go looking for it, but it makes Coach a destination you have to remember rather than something you glance at — from any other tab it's two taps plus a scroll through the More sheet.

I've been running a floating entry point locally for a while and it noticeably changed how much I actually use the Coach. Enough that it seemed worth asking whether it belongs upstream rather than keeping it to myself.

The idea

An optional floating Coach button hovering over the app shell. One tap opens the existing Coach screen.

• Off by default — nothing changes for anyone who doesn't switch it on (per CONTRIBUTING: "Optional features default OFF").
• Pin to one of four corners, or drag it anywhere. Corners resolve against the safe area with deliberate clearances, so a pinned button never covers the tab bar or the header — it sits beside the existing navigation, never on top of it.
• Lock position, so it can't be nudged out of place by accident. Locked still taps through to Coach.

Explicitly not in scope: no change to the Coach itself, no change to what it sends, no new network behaviour, no new computed or stored metric. This is display-only — the same category as TodayLayoutPrefs ("no metric is computed or stored differently; this only decides the SEQUENCE"), and a front door in the sense docs/CROSS_PLATFORM.md already blesses:

Platform-only features stay platform-only … These are front doors to the same shared core, not duplicated logic.

Alternatives you've considered

• A Today card instead — works, but only helps while you're on Today; the point is reaching Coach from Trends/Sleep too.
• Coach in the bottom bar — would mean demoting one of Today/Trends/Sleep/More. Clearly worse.
• Leave it in More — entirely reasonable, which is why this is a question and not a PR.

Additional context

Cross-platform. Happy to do both platforms in the same PR:

• iOS — an overlay in RootTabView's existing ZStack(alignment: .bottom), alongside FloatingTabBar; presents the existing CoachView.
• Android — the honest caveat: there's no FloatingActionButton anywhere in the codebase today. I'd implement it as a Box overlay inside AppRoot's Scaffold (matching how TodayScreen already does ad-hoc floating layers) rather than introduce Material3's FAB, routing to the existing Destination.Coach. Worth saying plainly: this would be the app's first floating nav affordance, and it sits next to GlassBottomBar where Coach already lives via the More sheet. If that's a direction you'd rather not take on Android, that's fair — better to know before I build it.

Persisted state would be install-specific UI prefs only (enabled / corner / locked / dragged position), mirrored with byte-identical enum raw values and matching storage keys across Swift and Kotlin — the TodayLayoutPrefs pattern. Nothing near the .noopbak whitelist.

Questions before I build anything:

1. Do you want this at all? "No thanks, More is the right home for Coach" is a perfectly good answer and saves us both a review.
2. Android twin in the same PR, or Swift-first with parity following? I can do either — Gemini landed iOS-first with Android parity in a separate PR (feat(android): native Google Gemini in the AI Coach — parity with iOS/macOS (#400) #472), and the daily brief is Swift-only today, so I wasn't sure which you'd prefer.
3. Version bump — mine or yours? CLAUDE.md says MINOR for a new feature and to bump MARKETING_VERSION + versionName together, but I didn't want to touch release numbering in a contributor PR without asking.

Either way — thanks for NOOP. The layering made this genuinely pleasant to build against.