[ryanbr]

Builds on and completes #551 (@exzanimo) — includes that PR's commit plus one fix on top. Merging this closes #551; if #551 lands first, this reduces to just the follow-up commit.

What #551 got right, and the one thing it left

#551 correctly fixes the Today steps tile tapping through to an empty apple-health/steps detail. But it does so partly by declaring the measured my-whoop/steps catalog entry before apple-health/steps, so MetricCatalog.all.first { $0.key == "steps" } now resolves to my-whoop. That lookup is used by three bare-key resolvers the PR doesn't touch:

• LabBookView:938 descriptor("steps") (confirmed reachable — steps is in its analysed set)
• CompareView's picker / legacy resolution
• the TabRoute.metric fallback

Since my-whoop/steps is empty for anyone not on a 5.0/MG, an Apple-Health-steps user (e.g. a WHOOP 4.0 owner who imports Health) would now get an empty LabBook steps correlation and Compare series where they previously saw their data. The reorder is load-bearing for #551's dashboard-card path (which routes by bare key), so it can't simply be dropped — the card needs the my-whoop entry to win.

The fix: route by source, not by catalog order

• TabRoute.metricSourced(key:source:) — a new route that resolves the exact (key, source) via MetricCatalog.metric(key:source:), order-independent, with a bare-key → Health fallback so a stale route can't dead-end.
• The Today steps card routes via .metricSourced(key: stepsDetailKey, source: "my-whoop") (both the measured steps and the steps_est fallback are my-whoop). The compact tile was already source-explicit in Fix Today steps analytics source #551 via todayStepsMetric/detailMetric.
• The reorder is undone — the measured entry moves back after apple-health, so first { key == "steps" } returns apple-health again and LabBook / Compare / TabRoute keep their prior behaviour. No regression, and the entry's catalog position no longer decides where anything taps through.
• Tests: drop the assertion that cemented the reorder; add a source-resolution test and a regression guard asserting bare-key steps stays apple-health — so a future reorder fails loudly instead of silently emptying those screens.

Net result: every steps surface that needs my-whoop reaches it explicitly by source; every surface that resolves by bare key is byte-for-byte unchanged from before #551.

⚠️ Verification limit — needs an Xcode run before merge

Same gap #551 has, stated plainly: this is app-target Swift (Strand/, StrandTests/), which has no Linux/CI path — swift-packages.yml covers only Packages/** and app-build.yml is disabled. This box has no Xcode, so I could not type-check or run the tests. What I did verify statically:

• all four changed files pass swift -frontend -parse (syntax clean);
• TabRoute.swift holds the only exhaustive switch over the enum (its unique cases .fullDayChart / .metricExplorer appear in no other file), so the new .metricSourced case is fully handled — no other switch breaks;
• cardLink(_:) takes a TabRoute; MetricCatalog.metric(key:source:) is static and reachable; MetricDetailView(metric:) is the existing initialiser.

Please run xcodebuild -project Strand.xcodeproj -scheme Strand test (or dispatch app-build.yml) before merging — that exercises MetricCatalogStepsTests and the compile that neither #551 nor this PR has had.

Not included (separate follow-up)

The card-level Apple-Health steps parity gap — Android's #377 blends imported Apple/Health-Connect steps into the Today steps value (real ?: imported ?: estimate) for both card and detail, while iOS omits the imported tier entirely. This PR keeps the iOS detail consistent with the iOS card (both my-whoop-then-estimate); closing the imported-tier gap touches stepCount itself and belongs in its own PR.

[ryanbr]

Self-review notes (re-reviewed my own change adversarially, verified against main):

Confirmed correct — no bug reintroduced. I checked whether reverting the reorder re-opens the original "steps tile → empty apple-health" bug at any bare-key push site. It doesn't: there are no other .metric("steps") navigation sites (grep-verified) — the Today card was the only one, and it now routes .metricSourced(…, "my-whoop"). Both Today surfaces (card line 629, compact tile line 864 via detailMetric) are source-explicit. The catalog order is apple-health(159) → my-whoop(165) → xiaomi-band(208), so first{key=="steps"} is apple-health, and the regression-guard test pins it.

One tradeoff worth stating plainly (it's why I'm flagging, not just approving my own PR): #551's reorder had a second effect I under-weighted — it incidentally gave WHOOP 5.0/MG users their measured steps in LabBook and the Compare picker (bare-key first{steps} → my-whoop), which they'd never had. It did that at the cost of breaking Apple-Health-steps users on those same screens. My PR removes both effects: LabBook/Compare go back to apple-health, which — verified against main — is exactly the pre-#551 state (there was no my-whoop/steps entry at all before #551, so measured steps were never in LabBook/Compare). So my PR is a clean restoration with no regression, and it correctly fixes the actual Today bug — but it does not give 5.0 users measured steps in LabBook/Compare. Doing that properly means making those two screens source/data-aware (resolve the source that has data for the user), which is a separate enhancement, not an order trick. Flagging so the choice is explicit rather than silent.

Pre-existing, not addressed here: the Compare picker lists three entries titled "Steps" (apple-health / my-whoop / xiaomi-band) because it enumerates the whole catalog without dedup or source-filtering. Two existed pre-#551 (apple-health + xiaomi-band); this is orthogonal to routing and out of scope.

Verification unchanged: syntax-parses clean; TabRoute.swift holds the only exhaustive switch so the new case is safe; but this is app-target Swift I can't type-check or run on Linux — still needs an xcodebuild -scheme Strand test / app-build.yml run before merge.