[Core] 2 - Surface recording storage failures

[KacperKozak]

What to build

Implement parity for fail-fast recording persistence and App Storage Failure from native write transaction through live state, simple non-blocking UI, and native Sentry reporting. Use GRDB records for ordinary recording inserts; retain tested aggregate SQL where appropriate.

Part 2 of the approved cross-platform persistence reliability plan. Android and iOS remain separate native implementations with shared observable contracts. Local planning document: docs/persistence-reliability-plan.md; this issue is self-contained. Type: AFK.

Likely files

• modules/vescape-core/ios/telemetry/TelemetryRepository.swift - production behavior or caller to inspect
• modules/vescape-core/android/src/main/java/expo/modules/vescapecore/recording/RecordingCoordinator.kt - production behavior or caller to inspect
• modules/vescape-core/ios/VescapeCoreModule.swift - production behavior or caller to inspect
• modules/vescape-core/src/index.ts - native bridge contract
• src/app/_layout.tsx - production behavior or caller to inspect
• src/config/sentry.ts - production behavior or caller to inspect

Implementation hints

Keep Room on Android and GRDB on iOS. Native owns durable truth; JS renders state and sends intents. Follow bidirectional @parity links and preserve bridge payloads. Custom SQL is allowed for migrations and aggregate updates with real DB tests. Use existing error UI and avoid a generic persistence/recovery framework. Diagnostics transport follows ADR 0031; Sentry handles errors independently of local event persistence. Use bun commands and appropriate scoped verification.

Acceptance criteria

• Failed write stops accepting recording samples, discards uncommitted batch, preserves committed data, and never reports success. No retry buffer or application retry loop.
• Storage broadly unusable produces persistent warning and disables affected storage actions; usable live speed, battery, alerts and Board connection continue. An operation-specific defect still fails recording without pretending every query is broken.
• Native Sentry adapter reports sanitized operation/error metadata once per episode independently of JS and application DB. No raw telemetry, GPS, SQL arguments or bound user data; offline delivery is best effort. Test invocation, and document an actual integration delivery check.
• Recovery is restart guidance, not programmatic app termination. Full disk guidance says free storage then restart. Clear state only after startup storage checks pass, then normal recording startup rules apply.
• Shared failure fixtures cover full disk and deterministic write failure, rollback, stopped ingestion, UI bridge state and reporting; add bidirectional native/TS parity tags.

Blocked by

• [Core] 1 - Test recording across hosts #461

Related

• [Core] 1 - Test recording across hosts #461
• [Core] 3 - Protect Board and settings saves #463
• [Core] 4 - Protect Favorite storage operations #464
• [Core] 5 - Protect Tune and alert storage #465
• [Core] 6 - Surface history read failures #466
• [Core] 7 - Cover remaining persistence contracts #467
• [Core] 8 - Verify migrations and backup restore #468
• [Core] 9 - Gate releases on storage contracts #469

[KacperKozak]

Implemented in a2a86d7 on persistence-reliability.