feat: prepare offline receive integration

[coreyphillips]

Related to synonymdev/ldk-node#117.

This PR prepares Receive Offline for a native FFOR provider. A user can select it for a supported positive amount within ready inbound liquidity. The current production provider remains unavailable, so the checkbox stays hidden until native integration and end-to-end validation are complete.

Description

• Adds Receive Offline to Auto and Spending invoice edits when the provider supports the exact amount.
• Validates the returned invoice and preserves request identity when retrying a lost preparation response after liquidity was reserved.
• Keeps a prepared QR visible and shareable after disconnection or node shutdown, using the expiry in the signed invoice and the native provider's negotiated policy.
• Checks native payment history before registering an invoice for display. Payment events, session changes and newer preparations invalidate stale results before the final display update.
• Keeps offline invoice strings in memory, separate from the ordinary persistent invoice cache. Matching payment events and expiry retire the displayed invoice.

Out of Scope

• Native integration: runtime scheduling, witness acknowledgement authority, invoice issuance, settlement and generated mobile bindings remain prerequisites tracked in ldk-node#117.
• Durable app recovery: the request identity and display session do not yet survive app restarts. Provider recovery and a persistent request journal are still required.
• End-to-end offline payments: tests use an injected provider and do not establish interoperable FFOR support.

Design

N/A - no design available.

Preview

N/A - the option remains hidden with the current runtime provider.

QA Notes

Manual Tests

• 1. Current dependency build → Receive → Spending → Specify amount within inbound liquidity: Receive Offline remains hidden.
• 2. With a supported provider → Receive → Spending or Auto → Specify positive amount within liquidity: Receive Offline appears; zero, excessive amounts and Savings edits do not offer it.
• 3. With a supported provider → select Receive Offline → simulate a lost preparation response → retry: the same request is recovered without a new reservation or ordinary invoice.
• 4. With a prepared offline invoice → disconnect or stop the node: its QR remains available until expiry; returning to invoice editing requires connectivity.
• 5. With a prepared invoice → receive its matching payment: the QR disappears and cannot return from a delayed preparation response.
• 6. regression: leave Receive Offline unchecked → show QR: ordinary receive and additional-liquidity navigation still work.

Automated Checks

• OfflineReceiveSessionTests.swift covers amount bounds, capability loss, preparation failures, stale responses, session reset, request identity and expiry.
• OfflineReceiveRegistrationTests.swift adds 14 tests for paid-history rejection, missing history, payment and session races, out-of-order preparations, expiry, and isolation from the ordinary persistent invoice cache.
• WalletViewModelReceiveTests.swift covers unavailable-provider refusal, session reset and ordinary receive behavior. ReceiveSheetSessionTests.swift checks the connectivity overlay bypass for an already prepared offline QR.
• The earlier broader simulator run passed 49 focused tests. After the cache and preparation-generation follow-ups, the final affected suite passed all 19 tests, including 14 registration tests and 5 wallet receive tests, on iPhone 17 with iOS 26.2. The final run included an app build. These counts describe separate runs.
• Scoped SwiftFormat and whitespace checks pass. Localization validation previously reported zero errors; this follow-up changes no localization strings.

This PR remains a draft. The generated Node dependency remains 0.7.0-rc.66 and the live provider stays unavailable.