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.

Native provider (September 23 update)

LdkOfflineReceiveProvider implements OfflineReceiveProviding over the ldk-node offline receive API through the small OfflineReceiveNodeClient protocol, and LdkNodeOfflineReceiveClient adapts the generated OfflineReceivePayment object onto it. The adapter compiles only under the OFFLINE_RECEIVE_LOCAL_LDK compilation condition (Configs/OfflineReceiveLocalLdk.xcconfig), because the committed synonymdev/ldk-node pin stays at 0.7.0-rc.66, and the provider is selected only by the developer toggle in Dev settings; otherwise UnavailableOfflineReceiveProvider remains and the checkbox never appears. The provider polls status until ready(bolt11), accepts the invoice only when its amount equals the request exactly and its payee is our own node id, persists the request identity as (requestId, amountSats, description) in UserDefaults so a Ready invoice is recovered with status(requestId:) after process death without a second prepare, keeps the identity on timeout so a retry resumes the same request, and clears it on terminal states. OfflineReceiveSettings derives the node configuration from the trusted Blocktank peer and the developer overrides, and LightningService applies setOfflineReceiveConfig when configured. Development defaults are documented as such in Docs/OfflineReceive.md.

Verification: in the default configuration (rc.66, unavailable provider bound) the affected suites pass on the iOS simulator with 52 tests across LdkOfflineReceiveProviderTests, OfflineReceiveRegistrationTests, OfflineReceiveSessionTests and WalletViewModelReceiveTests. The local-binding build with OFFLINE_RECEIVE_LOCAL_LDK against the generated framework was not completed in this checkpoint, so the adapter file's compilation against the real API is unverified. No device or end-to-end settlement test is claimed for the app.

This PR remains a draft. The committed Node dependency remains 0.7.0-rc.66 and the live provider stays unavailable without the local binding and the developer toggle.