Prevent LDK startup on mainnet

[Jainakin]

Mainnet already rejects Lightning API calls after #177, but still initializes the Lightning runtime. This change prevents LDK runtime construction, startup and resume on mainnet while keeping the Bitcoin/RGB wallet and required shared services available.

Changes

• Split native unlocked state into common wallet services and optional Lightning services. Mainnet unlock retains identity, signing and configured wallet persistence without starting Lightning chain sync, peer listeners, reconnect, gossip, event processing or sweeping. Its peer port is unused.
• Keep unconfigured browser nodes dormant until network selection. Mainnet construction, wallet attachment and active entry points cannot initialize or resume Lightning. Compatible handles share wallet/network policy; failed preparation leaves the shared node retryable.
• Allow on-chain wallets to open with historical Lightning records, including empty snapshots written by older on-chain-only releases. Preserve those records without interpreting them as evidence of either active channels or safe recovery.
• Restrict native mainnet node-store mutations and replication to the six existing common configuration mirrors. Historical Lightning/unknown records and their queued writes, deletes and malformed intents stay inactive. RGB wallet backup/restore retains its separate store and ownership requirements.
• Stage browser Lightning snapshots during networkless preload instead of replacing their localStorage copies. Supported consumers restore individual keys when needed; mainnet wallet use leaves historical localStorage and IndexedDB records intact, including divergent or single-store records. Media, proxy settings and shared virtual-channel preferences retain their existing hydration behavior.
• Keep the existing LightningUnsupportedOnMainnet API error. Remove this branch's MainnetLightningState refusal and mainnet-only constructor preload prerequisite. Update API/binding documentation and add persistence, upgrade and lifecycle regressions.

Non-mainnet Lightning retains its existing startup/networking paths. Shared storage and lifecycle changes are covered by targeted regressions. Dependency pins, signer policies and on-chain algorithms are unchanged; no wallet migration or new operating mode is introduced.

Rollout assumption and effects

The supported mainnet rollout is assumed to have no unresolved historical Lightning obligations: channels, funding, HTLCs, claims, sweeps or RGB Lightning obligations. The team must confirm this before rollout. No current Lightning users or payments, by itself, does not establish that condition.

Successful unlock does not verify this assumption or inspect every remote store, device or browser tab. Existing records are preserved but are not decoded, replayed, migrated, monitored or recovered. A wallet with unresolved obligations needs a separately reviewed recovery path before using this release. This release does not provide one.

Observable shared API behavior:

• Native mainnet network height is read from the wallet indexer on demand; indexer failures remain errors. Browser synchronous networkInfo* returns NetworkInfoUnavailable without a Lightning chain driver.
• Node/status values describe active Lightning components; zero Lightning counts are not wallet BTC balances. Identity and message-signing behavior follows the documented native/browser rules.
• Native mainnet pending_kv_writes counts active common-configuration retries, excluding preserved historical Lightning intents.
• Browser init/unlock still preload persistent state, but Lightning cache hydration is deferred until a permitted consumer reads it. Direct mainnet node construction and wallet attachment need no prior Lightning-state preload.

Future mainnet Lightning enablement must separately validate authoritative state restoration, ownership, channel monitoring, dependency/storage compatibility and downgrade handling before accepting Lightning activity. Preserving records now does not guarantee future recovery or make that later release a flag-only change.

Verification

Local verification for the changes through c7f118e:

Check	Result
Native library	302 passed, 0 failed; one ignored subprocess helper. The subsequently extended failed-unlock/VSS preservation test also passed separately.
Browser	Final source: 151 passed, 0 failed/ignored. Focused persistence/lifecycle subset: 7 passed; included in the total.
Upstream-base wallet upgrade	Rebuilt upstream ee855aa, started/stopped an unfunded on-chain mainnet wallet, then opened the identical wallet with the new daemon. Real manager, graph, scorer and replay-marker records remained byte-identical; address/identity persisted and the configured peer port could remain occupied.
Actual bindings	Rebuilt C and regenerated Python clients passed fresh/reopen/historical-state acceptance and the existing Lightning error contract with isolated mainnet-genesis fixtures. C ABI unit tests: 5 passed.
Persistence	Local/VSS fixtures cover divergent old records, pending puts/deletes/malformed intents, failed unlock/fence release, wallet backup, reopen and fresh-device wallet restore. Browser fixtures cover 23 historical key shapes, divergent/asymmetric storage, saved chain state and no mainnet runtime construction.
Builds/style	Daemon and C ABI builds, both single-backend production checks, strict native default all-target Clippy, root/C formatting, changed-WASM-file formatting and diff whitespace checks passed. OpenAPI YAML parsed.

Independent native/browser reviews found and addressed a passive supported-network event-history regression and added failed-startup preservation coverage. No unresolved blocking finding remains in those reviews under the rollout assumption.

Strict WASM Clippy still reports two unchanged upstream expressions (needless_update, unnecessary_sort_by). Full WASM formatting has the previously recorded unchanged lib.rs differences. They were not changed or suppressed. One new native test's address-reuse expectation and one test-helper compile path were corrected. A C ABI unit build reported cross-crate type mismatches after shared-target reuse; rebuilding the parent package cache resolved them without source or dependency changes.

These are local, unfunded fixtures, not funded-mainnet spending or historical-channel recovery. Current PR CI is blocked: 31 inspected jobs across five workflows failed authenticating to the existing rgb-consensus-s-bfa dependency before project compilation/tests. A maintainer needs to restore the workflow dependency access and rerun CI; no dependency pins or credential configuration were changed in this revision. The WASM package job was still running at the final readback. Final release packaging remains separate. The earlier October 2 Regtest SDK run was 11 passes and two reverse-payment failures; both later passed with local-only channel-capacity waits. One failure reproduced on upstream product code; the other did not in three bounded upstream attempts, so a scheduling effect was not ruled out. Those adapted results are not a clean unmodified-fixture or full SDK-suite pass.

Target is dev. The branch is based on ee855aa; upstream dev remains e2b39d5, adding release credentials and a logging lint correction. The upstream merged tree has not been executed in this verification.

[Jainakin]

Native CI is failing before compilation/tests because this PR comes from my fork and cannot access the credentials needed to fetch private dependencies.

[Jainakin]

Replaced by #195 with the same commits on a branch in this repository so CI can access the private dependency credentials.