fix(mobile): Android image metadata stripping fixes

[brow]

What changed?

Android image uploads now decode into sRGB before encoding, preserve PNG transparency, and structurally remove PNG and JPEG metadata that the relay rejects. Android 7.x retains a compatible decode path without raising the minimum supported API.

Real API 36 Bitmap.compress fixtures and relay contract tests cover sRGB and Display P3 PNG/JPEG output.

Why?

Android image uploads can fail with HTTP 422 when platform encoding emits ICC profiles or other non-canonical metadata. The client must meet the relay contract without weakening the relay's metadata policy.

How is it tested?

Added tests:

• Android sanitizer unit tests
• Android image processor instrumentation tests
• Relay media contract tests

Validated on API 24 and API 36, including Display P3 conversion and transparent PNG pixel preservation. Full pre-push mobile, Rust, desktop, and Tauri suites passed. Android lint has no new API findings and remains blocked by two existing unrelated errors.

Related: BOT-1389

Screenshots are not practical for this non-visual media-encoding change. Coverage verifies output color space, pixels, alpha, metadata structure, and relay acceptance instead.

🤖 This PR was authored with an agent.

[brow]

@codex review

[brow]

@builderbot review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[brow]

🤖 Re-reviewed exact head 77ea4bb. The unsigned SOI comparison and malformed double-SOI regression now enforce the relay contract correctly. I found no blocking issues. One non-blocking fault-visibility concern is noted inline.

[brow]

🤖 Independent review at exact head 7d8bd73 (second reviewer in the dual-review loop; delta from 77ea4bb is the narrowed upload-boundary catch).

Verified:

• Narrowing delta is correct and complete: runCatching {}.getOrNull() → try/catch (IllegalArgumentException). The sanitizer's fail-closed rejections (require) map to the normal upload-failure path, while error()'s IllegalStateException (unreachable format invariant) and OutOfMemoryError now propagate instead of masquerading as upload failures. This resolves the fault-visibility concern without widening behavior: a malformed Bitmap.compress output still never uploads unsanitized.
• PNG scrub: strict allowlist; drops eXIf/iCCP/tEXt/iTXt/zTXt/tIME/pHYs while keeping color-neutral and APNG chunks; length fields validated via 64-bit arithmetic (no overflow on hostile lengths); truncated chunks and missing IEND fail closed; trailing bytes after IEND dropped (tested with appended payload).
• JPEG scrub: keeps only zero-thumbnail-consistent JFIF APP0 and exact 12-byte Adobe APP14; drops APP1–APP13/APP15/COM (EXIF, XMP, ICC); entropy-coded data with byte stuffing and restart markers handled; nested SOI rejected using the unsigned comparison (77ea4bb fix) with the exact malformed double-SOI regression present; missing EOI fails closed; trailing bytes dropped.
• sRGB-before-encode: decodeSrgbBitmap targets sRGB at decode (ImageDecoder ≥P with software allocator, inPreferredColorSpace on 26–27) and re-draws to an ARGB_8888 sRGB bitmap otherwise, so dropping iCCP/APP2 cannot ship mis-tagged Display-P3 pixels; pre-O passes through where no color management exists. Instrumented test pins the P3→sRGB conversion within tolerance for both formats.
• Fixture integrity: all Bitmap.compress fixtures are byte-identical across crates/buzz-media, JVM-test, and androidTest resources (cmp clean); canonical sRGB PNG is a scrub fixed point (sanitized == input); regeneration procedure documented against API 36.
• Relay contract closes the loop: cargo test -p buzz-media android_ passes locally at this head — all four sanitized fixtures accepted, all three metadata-bearing raw encoder outputs rejected with MetadataForbidden. These Rust tests run in the CI Unit Tests job (rust path filter covers crates/**).
• CI: fully green at 7d8bd73 (30 success / 2 skipped publish jobs), including Mobile and Unit Tests.

Two non-blocking inline notes below (CI wiring for the new Kotlin JVM tests; pre-existing broad catch on the decode fallback). Verdict: approve.

[brow]

🤖 Non-blocking: the new JVM sanitizer tests (app:testDebugUnitTest) are not executed by the CI mobile job, which runs flutter test and flutter build apk only (assembleDebug does not run unit tests). The relay-side contract tests in crates/buzz-media do run in CI and pin the actual byte contract, so this is coverage redundancy rather than a gap — but wiring testDebugUnitTest into the mobile CI job in a follow-up would keep the structural scrubber tests from ever going stale unnoticed.

[brow]

🤖 Non-blocking, pre-existing pattern: this decode-path runCatching still catches every Throwable (including OOM), in contrast to the now-narrowed encode path. It guards a genuine documented fallback (ImageDecoder → BitmapFactory handles real decode failures), so converting decode faults into the BitmapFactory attempt is defensible; flagging only so the asymmetry with the encode path is a recorded choice rather than an accident.