fix(security): remediate mobile audit findings and remove Ark - #2561

LegacySeedViewScreen renders full mnemonics and their passphrases but was the only secret screen without the PrivacyScreen mixin, so Android FLAG_SECURE and iOS snapshot shielding were never applied. It is reachable from Bitcoin settings whenever the user has legacy seeds, not a debug-only screen. Mirror the AllSeedViewScreen pattern: enable on build, disable when the route pops.

The tor (Arti) networking dep was the only git dep pinned by an abbreviated 7-character SHA while every other one uses a full 40-char hash. Short hashes are ambiguity-prone and read like a mutable ref. b92e2bc5a404367298b6016f171df29d1aae66d0 is refs/tags/0.1.0 upstream and already the resolved-ref in the lockfile, so the resolved commit is unchanged and no dependency actually moves.

The half-the-amount fee cap lived inline in _claimFees, which is why the refund paths never got it. Move it into _cappedFees next to _absoluteWithFloor so there is a single place that decides how an absolute fee is floored and capped. No behaviour change: _claimFees is the only caller and the expression is unchanged.

The background watcher signs and broadcasts refunds with no user confirmation, at whatever rate the fee API returns. Claims were capped at half the swap since the amount at stake bounds what is worth spending, but all four refund sites (cooperative and script-path, LN send and chain) used the raw floored estimate. A fee spike, or a compromised custom mempool server, could therefore burn far more than the refund is worth: the new test shows 10000 sats of fees on a 1000 sat swap before this change. Route the refund fees through _cappedFees. The relay floor still wins over the cap so a dust refund stays broadcastable.

The receiver's max effective fee rate was hardcoded to 10000 sat/vB. In payjoin 1.0.0-rc.5 the receiver's mandatory contribution is contributed weight x max(BROADCAST_MIN, sender minfeerate), debited from our change output and rejected only above contributed weight x maxEffectiveFeeRate. The sender's minfeerate is attacker-controlled, so that constant was the only bound: a sender paying the 10000 sat minimum could set minfeerate just under the cap and burn roughly 1000000 sats of the receiver's own change, with no prompt anywhere in the automatic receive path. Derive the cap from the fastest tier instead, clamped to 20-100 sat/vB, which bounds the worst case near 10000 sats and keeps it bounded even if the user-configurable mempool server misreports. A fee lookup failure falls back to the floor rather than failing the receive. Deliberately NOT passing a minFeeRate: the crate takes max(ours, the sender's), so a floor of ours could only raise the burn.

_tryParseBolt11 truncated the invoice amount with msats ~/ 1000. BOLT11 denominates in millisatoshis and the pico-BTC multiplier makes sub-satoshi amounts expressible, so this discarded up to 999 msats per invoice and reported zero for anything below one satoshi. amountSat is not cosmetic here: SelectBestWalletUsecase compares it against wallet balances, and a zero reads as an amountless invoice rather than a small one. Round up instead, through a helper that can be unit tested. The parser itself needs the Rust bridge and cannot run in unit tests, but the rule can, and it is the rule that was wrong. Note this is the path the app actually uses: satoshifier's Bolt11Parser, fixed separately in the SDK, is not called from here.

Picks up the SDK-side audit work: the BIP21 amount, xpub base58check, BIP-380 descriptor checksum and bolt11 msat fixes in satoshifier, the required network and xpub type on the BitBox transport, the boltz rev pin, and the removal of Ark support. The Ark removal is a breaking SDK change, which is why the wallet dropped its own Ark code first. Turning on descriptor checksum verification immediately rejected a watch-only fixture here too: the same wrong checksum that the SDK carried, corrected to the value BDK accepts. NOTE FOR MERGE: this pins the SDK branch commit 7b343c5. It must be re-pointed at the commit that lands on the SDK's main before this is merged.

The image that produces the release APK bootstrapped its whole toolchain by executing remote code with no integrity check beyond TLS: rustup piped from sh.rustup.rs, FVM piped from an unversioned fvm.app/install.sh, and the Android cmdline-tools zip fetched from a _latest.zip URL. Everything downstream is built by those tools, including the Rust FFI crypto, so a compromised or swapped asset reaches the signed artifact. The rest of the repo already pins carefully, the base image by digest and the reproducibility jars by SHA256; this closes the remaining gap using the same sha256sum -c pattern. rustup now comes from its immutable archive path at a pinned rustup version, FVM from its release tarball reproducing the layout install.sh produces, and the Android zip is checked before use. The base image is pinned to linux/amd64, so single x86_64 digests are correct. Each digest was downloaded and computed here; the rustup one also matches the checksum rustup publishes beside the binary. NOT VERIFIED: the image was not built. This host is aarch64 with no x86 emulation, so the amd64 image cannot run here. The URLs, digests, archive layouts and the sha256sum -c pattern were each checked directly, but the first real build will be the first end-to-end proof.