[tigercraft4]

Fixes #642, #650

Summary

Scheduled debug exports (the daily strap-log + optional raw 5/MG capture) accumulated on disk indefinitely with no cleanup and no visible cap:

• Android (DebugExportScheduler.kt / LogExport.kt): the daily WorkManager job wrote noop-straplog-<stamp>.txt (+ .bin when a raw 5/MG capture exists) into the app-private cache/logs dir on every run, forever.
• iOS/macOS (ScheduledDebugExport.swift): the scheduled/"Run now" export wrote noop-strap-log-<stamp>.txt (+ noop-raw-capture-<stamp>.json) into the app's Documents directory, which is Files-visible (UIFileSharingEnabled), also forever.

Both platforms now mirror the existing BackupSync keep-count retention pattern:

• A pure scheduledExportStamp / scheduledExportStampsToPrune (Android) and exportStamp(fromFilename:) / exportStampsToPrune (Swift) pair extracts the timestamp embedded in each filename and computes which generations to delete beyond a keep-count — a day's log+raw pair shares one stamp and counts as one generation, not two. Unit tested on both platforms.
• Pruning runs automatically after every scheduled write (Android: end of writeScheduledExport; Apple: end of performExport, so it also covers the "Run now" button).
• Default keep-count is 14 generations on both platforms (these are small text/JSON files, not a whole-DB snapshot, so a longer default than BackupSync's 7 is reasonable).
• The Test Centre export card on both platforms gets:
  • A "Keep last exports" picker (3 / 7 / 14 / 30 / 60), wired to the new persisted setting.
  • A manual "Clear scheduled exports" action (with a confirmation dialog) that deletes every scheduled-export file immediately, regardless of the keep-count — independent of the daily toggle so files written while it was on don't outlive a later toggle-off.
• Interactive shares (noop-strap-log- interactive prefix on Android is spelled without the internal dash vs. the scheduled noop-straplog- prefix; on Apple, interactive saves go through the save panel / share sheet, never Documents) are never touched by retention or the clear action — only their own distinct filename prefixes are scanned.

Localization

New user-facing strings (retention picker label/blurb, clear button, confirm dialog title/message, clear-result toast/alert copy) are translated for the focus set de/es/fr/pt-PT, plus zh (Android values-zh) and zh-Hans/zh-Hant/it/ru (Apple catalog) to keep Tools/i18n_audit.py --ci's non-focus-locale ratchet from regressing. python3 Tools/i18n_audit.py --ci origin/main passes clean (exit 0).

Verification

• Android: cd android && ./gradlew :app:compileFullDebugKotlin → BUILD SUCCESSFUL. New unit tests added (LogExportRetentionTest.kt) covering stamp extraction, keep-N pruning (pair-counts-once), no-op within budget, and that interactive-share/unrelated files are never pruned. Not run against the JVM test task in this pass — only compile was verified per the build-verification checklist; the pure logic has no Android framework dependency so it should run under testFullDebugUnitTest without issue, but I have not executed that task here.
• Swift: xcodegen generate && xcodebuild -project Strand.xcodeproj -scheme Strand -destination 'platform=macOS' build → BUILD SUCCEEDED. Strand/System/ScheduledDebugExport.swift and Strand/Screens/TestCentreView.swift are shared between the Strand (macOS) and NOOPiOS targets (not excluded in project.yml), so the macOS build exercises the same source the iOS target compiles. New XCTest coverage added (ScheduledDebugExportTests.swift, @MainActor to match the type's isolation) but xcodebuild test was not run in this pass — only build.
• Not verified on hardware / device: actual on-device retention behavior (WorkManager daily job pruning over real days, iOS BGAppRefresh timing interacting with the prune, Files app visibility of the pruned/cleared state) was not exercised on a real strap or device. This is filesystem bookkeeping around an existing, already-shipped export feature, not a BLE change, but a human should sanity-check the picker/clear button once in the running app on both platforms.

Scope

One concern (retention for scheduled debug exports), both platforms, per the repo's cross-platform-parity rule. No schema/DB migration involved — this is pure filesystem pruning. UI additions use only existing design-system components (NoopButton/Palette/NoopType on Android, NoopButton/StrandPalette/StrandFont/Picker on Apple) — no hardcoded colors/fonts/spacing.

[ryanbr]

Checked the deletion scoping first, since that's the part that can hurt someone. It's tight on both
platforms: every delete is gated on the filename yielding a stamp, so nothing else in the folder is
reachable. The Apple side is actually stricter — it needs the extension to match too, so a file someone
dropped in Documents called noop-strap-log-notes.md survives. And noop-strap-log- doesn't match
noop-straplog-, so Android's interactive shares are safe. Fragile-looking, correct, and you tested it.

Two notes on your own caveats:

Your Kotlin tests did run. Android CI executed testFullDebugUnitTest and passed — Gradle just
doesn't name passing classes. So LogExportRetentionTest is covered.

Your Swift test has never run anywhere. StrandTests isn't in CI at all, and you ran build not
test, so ScheduledDebugExportTests is unexecuted by you and by us. Worth one xcodebuild test before
this lands — it's the only thing covering the Apple retention math.

Small thing: the two new clear-result toasts are raw English, so "new user-facing strings are translated"
isn't quite complete. LogExport.kt already has six raw toasts and no uiString, so you're matching the
file — not asking you to change it, just flagging that the audit can't see them because they go through a
variable.