Reliability: surface Health Connect writeback failures instead of silently returning zero

[tigercraft4]

Summary

Health Connect writeback failures are currently swallowed in several places. If permissions are revoked or Health Connect rejects a record type, the UI may keep writeback enabled without telling the user that writes are failing.

Evidence

• android/app/src/main/java/com/noop/ingest/HealthConnectWriter.kt:121-129 wraps each write concern with runCatching(...).getOrDefault(0).
• android/app/src/main/java/com/noop/ui/AppViewModel.kt:1855-1860 launches an immediate writeback using runCatching and does not expose failure state.
• android/app/src/main/java/com/noop/ble/WhoopBleClient.kt:1829-1832 logs success counts but has no failure path.

Risk

A user can believe Health Connect sharing is active while some or all record writes are failing. This is both a reliability issue and a privacy/consent issue because the app's state no longer accurately represents external sharing behavior.

Suggested fix

• Return a structured writeback result with per-type success/failure counts.
• Store/display last writeback status in the Data Sources UI.
• Log non-sensitive error categories for diagnostics.
• Consider disabling the toggle or prompting for permissions again on SecurityException.

Audit context

Found during a static reliability/privacy audit. The permission request flow itself is gated and opt-in; the finding is about post-permission observability.