fix(shareable): fund cash links copied from the Sharesheet

[bmc08gt]

Tapping the Sharesheet's own Copy button on a cash link produced no "Did you send the link?" modal, and the gift card was never funded, so the link the user pasted could not be collected. initiateGiftCardFunding only runs from onShared(ActionTaken), so a share the app does not notice is a link that does not work.

It is awkward to reproduce on purpose, because the sheet offers two different controls that both say Copy. A copy-to-clipboard app target, such as Drive's SendTextToClipboardActivity, is a real component and has always worked. The Sharesheet's own Copy chip in the preview header is not a component at all.

Why the receiver missed it

The same PendingIntent comes back two ways:

system Copy chip : extras {share_id, CHOOSER_RESULT}
Messages target  : extras {share_id, CHOOSER_RESULT, CHOSEN_COMPONENT}

ShareBroadcastReceiver read only EXTRA_CHOSEN_COMPONENT and did nothing when it was absent, which left ShareResult.CopiedToClipboard unreachable. Nothing in the codebase could produce it.

Why the clipboard fallback did not cover it

checkForShare() was meant to catch exactly this, and could not, for two independent reasons:

1. It sat behind foregroundRefreshed.compareAndSet in onAppInForeground, which runs on ON_RESUME, but onAppInBackground resets that flag from ON_STOP. The Sharesheet is translucent and pauses the activity without ever stopping it, so the pass was still spent and the call returned early.
2. Even once reached, the read happens before the window holds focus, and Android denies clipboard reads to an unfocused app: Denying clipboard access to com.flipcash.app.android, application is not in focus. A denied read reports no clip at all, which is indistinguishable from an empty clipboard.

The change

• ShareBroadcastReceiver parses EXTRA_CHOOSER_RESULT when no component is attached and relays CHOOSER_RESULT_COPY as a new EXTRA_COPIED_TO_CLIPBOARD. That extra is API 35+, so the parse is guarded for minSdk 29.
• InternalShareSheetController consumes it as CopiedToClipboard. awaitClipboard() polls every 50ms up to a 1s grace period so the read lands once focus arrives, which is the only route on API 29 to 34, where the Sharesheet reports the copy not at all.
• checkForShare() moves above the foregroundRefreshed gate in RealSessionController, staying below the auth gate. Deduping the expensive refresh pass is unchanged and covered by a test.
• report() cancels any poll still in flight, so a share the Sharesheet reports mid-wait is not answered twice. A blank entropy no longer matches, since it is contained in every string and would fund a link the user never shared.

15 tests cover both receiver routes, the clipboard wait and its grace expiry, double-report protection, and the lifecycle gate.