fix(app): surface Limitless flash-drain stalls instead of silent success

[formed2forge]

Summary

The Limitless pendant's protocol makes flash-page drain and recording mutually exclusive (mode command 8) — there is no mode that serves stored pages while a recording session is open. When a drain stalls because the pendant is recording, or because it's full and stuck in recording mode, the 30s stall detector in FlashPageWalSyncImpl ends the pass, WalSyncs.syncAll discards the result, and SyncProvider fell through to toCompleted() — the user saw "synced" while nothing transferred and nothing told them why.

This PR closes the silent-ops half of that failure:

• FlashPageWalSyncImpl re-queries device status on a stall, still in batch mode, and classifies it via FlashSyncStallReason: recordingSuspected (newest_flash_page advanced past the enumerated end while the drain starved — the pendant is minting pages it won't serve) or deviceFull (flash storage full, pendant halts recording but stays armed and serves no pages until the button stops it). Exposed through WalSyncs.flashStallReason and stamped on the flash_page_download_partial event; the read that decides the reason is now logged via flash_page_stall_classified since it hadn't been observed under a real full-flash condition yet.
• SyncProvider maps a classified stall with no new conversations to a user-facing error state instead of silent completion — l10n'd across all 49 locales (pendantRecordingSyncBlocked, pendantFullSyncBlocked).
• The sync error banner (sync_page.dart) was clamped to 2 lines + ellipsis, truncating the new (longer) recovery messages mid-word, worst at larger accessibility text scales. Extracted into a small, tested SyncErrorCard widget that reflows the full message instead of clamping it.
• Unrelated stalls (plain transfer lulls) keep the existing resume-on-next-sync behavior.

The protocol limitation itself isn't fixable app-side; this only ensures the user learns why sync stopped and how to unblock it (stop recording via the hardware button, then sync again).

Not covered by this PR: while an upload (as opposed to a BLE drain) is in progress, SyncProvider.isSyncing hides the "Sync Now" button entirely, so there's no UI pathway to start a new drain if the pendant's flash fills up mid-upload. That's a distinct UX gap needing its own design (separate "offload device" action vs. running drain/upload concurrently) — filed as #12265.

Branch history note

This branch was rebased onto current upstream/main (it had drifted ~8300 commits behind). Five commits unrelated to Limitless sync — an abandoned side-thread on iOS community-build signing config (dynamic DEVELOPMENT_TEAM/APP_GROUP_IDENTIFIER, dev-entitlement stripping) — were dropped during the rebase rather than carried forward: that work already has its own more current, still-open effort (#7641 / fix/ios-community-build), and mixing it into this PR would just reintroduce a stale, superseded version of it. The generated app_localizations*.dart l10n files were regenerated with flutter gen-l10n after the .arb sources were hand-merged (verified as pure additions matching the .arb diff — see the chore(app): regenerate l10n output commit).

Test plan

• bash app/test.sh — full suite, see CI/PR checks for pass/fail
• dart format --line-length 120 on regenerated l10n output — no changes (gen-l10n already formats to the repo's line length)
• Verified .arb merges are valid JSON and the regenerated .dart getters are pure additions matching the .arb diff
• Live pendant-in-hand verification of the deviceFull stall path is still pending upstream (per the original commit's notes: only reproduced via injected status in a test harness so far, not yet observed on real hardware with a genuinely full pendant)

Failure-Class: new

New class added in this PR: FC-drain-stall-completes-silently (.github/failure-classes/FC-drain-stall-completes-silently.json) — a device-storage drain stall caused by a structurally-unservable state (protocol mode conflict, full storage still armed for recording) must be classified and surfaced as an actionable error, never allowed to fall through to a generic "completed, nothing new" success.

🤖 Generated with Claude Code

[Git-on-my-level]

Thanks @formed2forge — this closes a genuinely nasty silent-failure mode, and the implementation is careful. Detailed pass below.

What I verified

• flash_page_wal_sync.dart: classifyStall() is well-grounded — free_capture_pages is a real field the DeviceStatus parser populates (marker 0x20 in _parseStorageStateFromDeviceStatus), so the deviceFull branch reads actual firmware state rather than an assumed key. Precedence is right (deviceFull checked before the recording heuristic, with a test pinning "full takes precedence over newest-page movement"), and the false-positive guards point the safe way: a missing/partial status read and a newest page behind the enumerated end (pages ACKed away) both classify as unknown, which preserves today's behavior.
• Reset semantics are clean: _lastStallReason is reset to none at the top of both syncAll() and syncWal(), so a stale classification can't leak into the next pass. Classifying while still in batch mode, before enableRealTimeMode(), is the right window.
• sync_provider.dart: the two new branches in _performSync sit before the toCompleted() fallback and only fire on a classified stall — plain transfer lulls (unknown) keep the existing resume-on-next-sync behavior, pinned by the provider test. The English fallback for headless runs is pragmatic.
• sync_error_card.dart + sync_page.dart: extracting the banner and dropping maxLines: 2/ellipsis is a real accessibility fix, not churn — the recovery instruction is exactly what used to get cut, and the widget test asserts both no-clamp and no-overflow at 2.0 text scale.
• l10n: both new keys (pendantRecordingSyncBlocked, pendantFullSyncBlocked) are present in all 49 locales; the .arb diffs are purely additive (plus the trailing-comma fix on prerecordedTranscript).
• .github/failure-classes/FC-drain-stall-completes-silently.json matches the schema of the existing failure-class entries.

Checks are green on this head (Dart Analyze and Tests, Android Compile Smoke, Generated Files, Formatting, Hygiene; the skipped jobs are out-of-scope skips). No split needed — it's one outcome (surface flash-drain stalls) and the l10n churn is intrinsic to it.

Minor observations (non-blocking)

1. In _performSync, _hasConversationResults(result) takes precedence over the stall branches. In a combined pass — pending phone-file uploads that produce conversations and a stalled flash drain — the user still sees "completed" and the stall is silent again. No data is lost (the flash WAL stays miss and the next sync resumes), but it's a narrow residual path worth a follow-up, e.g. a partial-success-plus-stall state.
2. The new error messages are resolved to localized prose at state-set time (_pendantRecordingMessage() via globalNavigatorKey), while the newer convention in this file (pendingUploadErrorCode) keeps provider state machine-readable and lets surfaces own localization. It follows the ai_app_generator_provider precedent, so fine — just noting the two patterns now coexist.
3. The deviceFull semantics rest on firmware behavior under a real full-flash condition that (per the PR notes) hasn't been observed live yet. The defensive design (misclassification degrades to unknown → current behavior) plus the new flash_page_stall_classified telemetry is the right mitigation — worth watching that event after release.

Leaving the merge call to a maintainer; the one hardware-dependent assumption behind deviceFull is the only thing that can't be verified from code.

---

by AI on behalf of David — happy to re-review after changes; ping @Git-on-my-level with need human response if a human ruling is required.

[formed2forge]

@mdmohsin7 — ping for review. Code review by Git-on-my-level is complete and positive, CI is green. Just waiting on your sign-off.

[formed2forge]

Rebased onto current upstream/main — one merge conflict in sync_page.dart's _buildSyncErrorCard resolved by keeping the PR's SyncErrorCard widget refactor (upstream had added an Expanded wrapper inline; the PR's widget extraction supersedes that). All 6 commits land cleanly. CI should re-run.

[kodjima33]

Verified the FlashSyncStallReason/deviceFull classification is not yet on main (bug is real). CI green, scoped code change (bulk of diff is auto-generated l10n across 49 locales). Confidence 4/5 bug fix — merging.