Apple Health import: write steps to DailyMetric — iOS + Android (#89)

[ryanbr]

Fixes #89 (Apple Health steps not counted) on both platforms. Supersedes #97.

Root cause

Apple Health steps never reached DailyMetric.steps, so they never surfaced in the sourced-daily step arbitration:

• Android: FusionDayAdapter → WhoopRepository.dailyColumn("steps") = d.steps
• iOS: metricValue = d.steps (Repository.swift:1792)

The importer wrote every other Apple-derivable daily field into DailyMetric, but the steps column was silently omitted from the constructor on both platforms — so DailyMetric.steps was always null for Apple Health.

Fix

Set steps in the DailyMetric the importer builds:

• Android (AppleHealthImporter.kt): add steps = d.steps?.let { Math.round(it).toInt() } to the construction, and || d.steps != null to the hasDailyMetric gate so a steps-only day (no HR/HRV/sleep) still creates the row.
• iOS (AppleHealthImport.swift): add steps: d.steps.map { Int($0) } to the construction (no gate — it already maps every day).

Why this over #97

#97 added only the gate clause (|| d.steps != null) but the constructor still never set steps — so it created bare all-null DailyMetric rows and left DailyMetric.steps null. #89 stayed broken. The actual gap was the missing constructor field; this sets it (plus the gate, for steps-only days).

No double-count: Apple steps win by arbitration tier (intended), and the aggregator already takes max-per-source, never a cross-source sum (#589).

Verification

• Android: :app:compileFullDebugKotlin passes; the parse-side step aggregation is already covered by AppleHealthImporterToleranceTest (stepsDoNotDoubleCountAcrossSources).
• iOS: rides the next build (app target can't compile on WSL); the added field mirrors the 8 sibling fields already in the same constructor.
• No new unit test: the row-building takes a private day-aggregate + a Room repo with no JVM test seam, so covering it would need a refactor larger than the one-line fix. Flagging that explicitly rather than hiding it.