Put the Loopky fox in the middle of a share QR code

[jvsena42]

A deck or profile QR now carries the app icon in its centre, so a code on someone's screen reads as a Loopky link before it is scanned rather than as an anonymous square. Sign-in and Lightning codes are untouched — their payloads are dense one-shot credentials with nothing to brand.

What it costs, and why it is safe

The mark destroys the modules under it, so both platforms raise the correction level from M to H whenever a mark is drawn: H recovers ~30% of the code, and a 24% plate covers ~6% of its area. That margin is measured rather than asserted — the shared PNG was decoded back with zxing at 816, 400, 240, 160 and 120px, the last being about two pixels per module. Widening the plate without moving the level is how this silently stops scanning.

Two things the platform gets wrong if left to it

• The launcher foreground is drawn inside the adaptive-icon safe zone, so a fifth of every edge is transparent. It is trimmed to its own alpha bounds rather than scaled by a hardcoded factor, so redrawing the icon cannot quietly shrink the mark to two thirds of its plate.
• decodeResource picks the device's own density bucket, but the shared PNG's plate is 173px everywhere — an mdpi phone would upscale 60px of fox into it and send a soft mark that nothing on that device shows. The xxxhdpi art is asked for by name.

Each platform uses its own launcher art rather than a shared asset, so the mark in the code matches the icon on the home screen either side.

Verification

Driven on emulator-5554 against staging at both the compact and expanded width classes: deck share, profile share, the attached PNG and the four downscales all decode to the exact URI. :androidApp:assembleDebug and detektAll pass. journeys/RESULTS.md has the table.

iOS is unverified. This was done on a Linux box, so no Swift here was compiled, let alone driven — the change mirrors the Android one and follows the file's existing patterns, but it needs a Mac before merge.