feat(scanner): scan an image shared into the app

[bmc08gt]

Phase 2 of scan-from-gallery. Flipcash now appears in the share sheet for an image, and a shared image is scanned by the same path Phase 1 built for a picked one — the Kik-code ladder, then a QR fallback, then DeeplinkType.isScannable.

Phase 1 is #1509; the ScanFromGallery flag it shipped behind was retired in #1520, so this is unconditional.

How it fits together

A share can't reuse the deeplink route: Rinku's DeepLinkListener only sees intent.data, and the image arrives in EXTRA_STREAM. So MainActivity takes the Uri off the intent and hands it to a @Singleton SharedImageChannel, mirroring the existing EmailCodeChannel / LocalEmailCodeChannel pair.

The tab switch happens in App.kt rather than in the scanner, because Scanner() isn't composed while another tab is showing. Scanner() then consumes the pending Uri and calls the existing onImagePicked lambda unchanged.

The Uri is cleared before the scan starts, not after, so a failed scan isn't retried on every recomposition and a rotation mid-scan doesn't start a second search.

Why isScannable carries more weight here

A picked image is one the user chose. A shared image is one somebody else put in front of them, which is the shape of a phishing attempt against the login route — a crafted /login QR is an account takeover if it's allowed through. isScannable is the whole defence, and DeeplinkScanPolicyTest already asserts it, so this extends that test rather than adding a parallel one.

Making the app a share target turned out to open a second way in. The share filters are the only ones on MainActivity that don't pin a scheme and host, and a filter naming just a mime type accepts content: and file:. Rinku is installed with no DeepLinkFilter, so the listener routes whatever is in intent.data, and isLogin() matches on the first path segment alone. A sender could therefore attach content://evil.example/login/#/e=... to an ordinary image share and reach tapped-link handling, which — unlike the scan path — will open /login.

consumeSharedImage clears data and removes EXTRA_STREAM on any SEND/SEND_MULTIPLE, before super.onNewIntent, which is where the listener runs. It can't wait until an image is found, because a sender after the deeplink just omits the image. A VIEW intent is left untouched, so App Links still work.

Also worth a look

• An image shared during onboarding or on the restriction screen used to navigate away from it, and navigateAll clears the back stack. The gate now requires AuthState.Ready, and holds rather than decides while auth is still resolving.
• The scan ran under the biometric app lock — the overlay draws over the scanner rather than replacing it, so the effect beneath still ran, and a shared cash link would sign and submit a grab on a locked app.
• Removing EXTRA_STREAM also stops singleTask replaying the same share on every restore from recents after a process death.

Known, and deliberately not fixed here

The reused path emits the whole gallery funnel, not just its first event: galleryImagePicked, then galleryScanSucceeded or galleryScanFailed, all from inside the onImagePicked lambda that both entry points now share. So a shared image counts as a gallery pick at every stage, and Phase 1's funnel over-reports throughout rather than only at the top.

Fixing it means a Source property on the three Gallery Scan entries in libs/analytics-events/events.toml (lines 402-426) — a change to the shared cross-platform contract, plus a parameter on three call sites here. iOS doesn't send these through the contract yet; its versions drift by name, as those entries' own drift notes record. So the property wants settling across both platforms rather than landing here. Raised with the sessions working on the contract, and nothing in this PR forecloses it.

The iOS half of Phase 2 is a share extension — a different mechanism, shipping independently.