fix(ark): warn that a Bark address is not a passive receive method

[CypherBoxLLC]

What

Adds a caveat to the Bark address option on the receive screen: it is not a passive, leave-it-and-forget-it way to be paid.

Uses the same amber treatment already on this screen for the on-chain minimum, so no new pattern.

Why

A capsule arriving at a Bark address is short-lived, and the expiry reminders are local OS alarms. Every call site that schedules them is in the foreground:

useArkSync.ts:985                     (sync loop)
useArkoorReceivePrompt.ts:183/416/443 (arkoor receive hook)

So the notification that would tell the user to open the app can only be created by opening the app. If someone is paid at a shared Bark address while the app is closed, no alarm was ever scheduled and nothing in the system can reach them.

Nothing external can cover it either: the push server watches on-chain addresses and Lightning, while an arkoor VTXO is off-chain and known only to the ASP.

The other two receive methods are materially safer and are left alone:

• Lightning: the invoice is generated in-app and paid seconds later, so the user is almost always foregrounded and the receive hook catches it.
• On-chain: board outputs carry roughly 28 days, so there is ample runway to open the app for unrelated reasons, and users are already advised not to leave the app unopened for long.

On the wording

Draft, expected to be rewritten.

Deliberately no number. The received-capsule TTL is set by the server, the spec only has it as "roughly 3 days" from a single measurement, and unlike minBoardSats there is no live value to read at address-display time because the VTXO does not exist yet. A wrong-but-specific figure would be worse than a vague-but-true one. If a number is wanted, the received-capsule TTL should be measured properly first.

Verification

• tsc: 405 errors, zero differing lines against a baseline regenerated from the unmodified tree
• npx jest -b -i tests/unit --rootDir .: 36 suites, 251 passed, 1 skipped

Copy-only, no logic touched. Not yet verified on device: a mainnet unilateral-exit test is running and the device build serves JS from a tree holding uncommitted endpoint overrides for it.

[CypherBoxLLC]

Correction: this was shipping to a screen nobody can reach

The caveat was originally added to ArkReceiveScreen. That screen is registered in no navigator and is unreachable. Its own comments record why: Ark receive moved inline into the receive bottom sheet, because the three options it exposed map onto a tabbed sub-menu so the user never leaves the sheet.

So the warning shipped to nobody, and the reporter could not verify it because it was not on screen.

Now added to the Bark tab in ReceivedListNew, under the address and QR, using the same amber treatment as the dust tip already at the top of that sheet. ArkReceiveScreen is restored to its state on main rather than left carrying dead copy that implies otherwise.

Branch also merged up to current main. Verification re-run: 52 suites, 546 passed, tsc 400.