feat: long-poll on the storage nodes; one-time background prompt; no startup "Device ready" flash

[cryptskii]

Summary

Transfers settle as soon as the other side's step lands, instead of at the next poll.

Storage node: POST /api/v2/b0x/wait (B0xWaitRequest)

• Answers 200 with the spools that hold an entry at or after the device's mark for them. It answers at once if one already does; otherwise it holds the request until one lands.
• Every submit wakes the waits held on that spool. The wake-up is in-process: a node's spool is written only by its own submit route.
• A wait that runs out answers 204. The bound is AppLimits.wait_bound (25 s deployed), enforced by a TimeoutLayer on the wait route. The node reads no clock, keeping to storage spec §1 rule 4 (tests/no_clock_reads.rs).
• The route sits outside the node's request timeout and concurrency limit. It has its own cap of 4096 held waits, beyond which it answers 503. A held wait holds no database connection.
• Nothing is read, marked or changed by a wait.

App: dsm_sdk::sdk::inbox_waiter

• Runs beside the inbox poller, while the poller runs: in the foreground, or in the background while a transfer settles.
• Holds one wait per member over every inbox route the device reads, and wakes a sync the moment any member answers.
• Each spool's mark is where the last sync read that member's spool to its end, kept in memory.
• When a sync moves the routes, the waits are restarted on the new ones. A member that fails, or doesn't serve waits (404 before the redeploy), is rested for 30 s. Repeated instant answers back off from 1 s up to 30 s.
• While the waits cover the fleet (N − K + 1 members, so every delivery lands on one of them), the poller drops to a safety net: 5 s while settling (was 2 s) and 30 s on screen (was 5 s). Otherwise it keeps its current cadence.

Android: one-time background prompt

• BatteryExemption opens the system's "let this app run in the background" dialog once per install, the first time the app starts with a wallet while still battery-optimised.
• This keeps the wallet's own node connection alive through Doze. No push service is involved.

Frontend: no "Device ready" flash at startup

• The chip-trace "Device ready" scene played on every move from the publishing screen to the wallet. An ordinary launch can pass the publishing screen for a moment.
• It now plays only when the securing screen was shown in that run.

Related Issues

Follows #1107 (2 s / 5 s polling stopgap).

Testing

• cargo fmt --all -- --check, and clippy -D warnings on dsm_sdk and dsm_storage_node
• scripts/real_code_guard.py clean
• Storage node: full cargo test green, including the new tests/b0x_wait.rs and the wait case in tests/resource_limits.rs, run against Postgres
• SDK: inbox_waiter / inbox_poller tests, including a wait held at in-process nodes over TLS (test_support::nodes) and answered when a delivery lands
• Frontend: FxProvider tests, including a new case for a launch through the publishing screen, which fails on the old cue; tsc and eslint clean
• make android: not built locally (no Android SDK in this environment); CI builds it

Checklist

• I kept unrelated changes out of this PR
• No TODO|FIXME|HACK|XXX added

Notes

• The waits need the nodes redeployed. Until then the app gets 404, rests each member, and polls exactly as it does today.
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS is fine for side-loaded beta builds. A Play Store release needs Google's approval for it, or a switch to opening the battery settings list instead.
• Code-map pins are repinned in a follow-up commit on this branch once the map and evidence run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y4wDTToHmJfkYYJvMKXt3u

---

Generated by Claude Code