migrate-db writes irreversible tombstones without verifying target backend support

[SoulReaver-SS]

Description:

lndinit migrate-db writes tombstone markers inside the source bbolt database files upon successful migration. These tombstones are permanent and cause LND to refuse to open the bbolt files with:

refusing to use db, it was marked with a tombstone after successful data migration

The problem: lndinit does not verify that the target LND binary actually supports the destination backend before writing these tombstones. If the LND binary was not compiled with the required build tag (e.g. kvdb_sqlite), the migration completes successfully but LND fails on startup with:

error opening sqlite graph DB: unknown database type

At this point the user is stuck. The sqlite files exist but LND can't use them. The bbolt files are tombstoned and LND refuses to open them. The only recovery path is restoring from a pre-migration backup. If no backup exists, the node's channel state is irrecoverably lost.

What happened

1. Ran lndinit migrate-db from bbolt to sqlite on a BTCPay Server LND node (v0.19.3-beta)
2. All five databases migrated and verified successfully (channeldb, macaroondb, decayedlogdb, walletdb, neutrinodb)
3. lndinit wrote tombstones into each bbolt file
4. LND failed on startup because the BTCPay LND image isn't compiled with kvdb_sqlite
5. LND also refused to fall back to bbolt because of the tombstones
6. Had to restore all bbolt files from a manual backup made before migration

What should happen instead

Any of the following would prevent data loss:

1. Pre-flight check: Before migrating, verify the target LND binary supports the destination backend. Fail early with a clear error if it doesn't.
2. Revert command: Provide lndinit migrate-db --remove-tombstone or lndinit migrate-db --revert to strip tombstones from bbolt files and restore them to a usable state.
3. Deferred tombstone: Don't write tombstones immediately. Instead, provide a separate lndinit migrate-db --finalize command that writes tombstones only after the user confirms LND started successfully on the new backend.
4. At minimum: Print a loud warning before writing tombstones that this operation is irreversible and the user should have a backup.

Environment

• lndinit: v0.1.33-beta (linux-arm64)
• LND: v0.19.3-beta (BTCPay Server Docker image, missing kvdb_sqlite build tag)
• Platform: Raspberry Pi 5
• Active Lightning channel with real funds at risk

[0xfandom]

Picking this up. Plan: implement option 4 from the issue first since it's the lowest-friction floor and unblocks future work on options 1/3 — print a loud, multi-line warning banner at the start of migrate-db explaining that tombstones are irreversible and recovery requires a pre-migration backup, plus a per-DB warning right before each tombstone write. No new flags, no breaking change. Options 1 (pre-flight binary build-tag check) and 3 (deferred --finalize) are real fixes but need separate design discussions — happy to follow up with either if you want. PR shortly.