feat(app): increase offline sync chunk size from 1 to 3 minutes

[mdmohsin7]

Summary

• Bump sdcardChunkSizeSecs from 60 → 180 in app/lib/services/wals/wal.dart — the chunk size used when audio is synced from device storage to the phone (SD card, ring, and offline storage WALs; all consumers derive frame counts from this constant).
• The phone-side live WAL buffer (chunkSizeInSeconds) intentionally stays at 60s, since it holds frames in memory before flushing — tripling it would triple audio lost on a crash.

Why

• Fewer mid-word cuts: chunk boundaries are blind frame-count cuts (not VAD-aligned) and each file is transcribed independently, so words straddling a boundary get mangled. 3-min chunks = 3× fewer cut points per hour of audio, plus more context per Deepgram request (accuracy, punctuation, per-file language detection) and more voice per speaker for diarization/speaker ID.
• 3× less overhead: fewer upload requests (rate-limiter pressure), VAD calls, STT calls, closest-conversation Firestore lookups, and conversation read-modify-write merges.
• Conversation grouping is unchanged: contiguous chunks have ~zero gap at boundaries, so the backend's ±2 min closest-conversation lookup chains them into the same conversation either way; real pauses hit the same 120s thresholds regardless of chunk size. 180s stays well under the backend's 300s VAD/STT segment cap (SYNC_MAX_VAD_SEGMENT_SECONDS).

Trade-offs (accepted)

• Coarser resume granularity: an interrupted BLE transfer re-downloads up to 3 min instead of 1.
• First uploadable file appears after 3 min of transferred audio instead of 1.

Test plan

• All 131 WAL-related unit tests pass (phone_mic_wal, local_wal_sync, wal_recovery, session_wal_sync, sync_response_handling, sync_rate_limit_reconciliation, wal_sync_display_state, wal_upload_resilience).
• flutter analyze lib/services/wals/ — no new findings (only pre-existing infos/warnings).
• Not yet exercised on a physical device; needs an on-device offline sync run before merge.

🤖 Generated with Claude Code