Mainnet: provide canonical recovery for legacy active PrivateNotes

[Community-AI-tools]

Problem

A historical mainnet PrivateNote is active, has no locks and no busy operation, but cannot be closed through a current official DexDo CLI.

The note has two distinct balances:

• 100 SHELL in the trading record
• 350 SHELL physical ECC[2] in the account gas pocket

The intended canonical close-out is note withdraw followed by note sweep to the operator's already-bound Hot wallet.

Reproduction

1. Use the current mainnet 4.0.36 deployment manifest and official dexdo 0.2.1.
2. Run dexdo note balance --note-addr <legacy-note> --raw.

Actual result:

Error: note <legacy-note> is not current PrivateNote:
actual code_hash 57e85fa67cc90284b907ea7e9d8c6d35830c02d14bd04d4be6ec884b5748ca0c,
expected code_hash acf19e140b58469a50165bcbda88cca952b2036678f1f5823b6a6bebd3fc32b1

The current CLI correctly fail-closes before a write.

A preserved historical CLI can read that note and reports the balances and idle state, but its doctor fails before signing because its Root contracts and manifest pins are older than mainnet 4.0.36.

A read-only inventory of preserved binaries found no official binary that both:

1. passes doctor against mainnet 4.0.36; and
2. recognizes this historical PrivateNote generation for canonical withdraw / sweep.

Expected

Provide an official, fail-closed recovery path for an old active PrivateNote on a current mainnet:

• recognize a previous supported PrivateNote code hash only for recovery;
• verify owner, no orders, no locks, and no busy operation;
• execute the existing canonical close-out flow (withdraw then physical ECC[2] sweep) to an explicitly supplied canonical destination;
• re-read source and destination and emit evidence;
• reject unknown or unsupported code hashes without signing.

This must remain a DexDo CLI/manifest-supported route. Direct ABI/TVM calls or local contract patches are not acceptable.

Acceptance evidence

• current doctor passes against mainnet 4.0.36;
• legacy note is recognized for the recovery route;
• trading balance is withdrawn;
• physical ECC[2] balance is swept;
• source note and destination wallet are re-read after each irreversible step.

[Community-AI-tools]

Additional independent recovery blocker (current reproduction, no new spend):

A crash-safe note deploy recovery is fenced at deposit_voucher.submit_maybe_sent=true, with no pn_address. The original wallet has now been restored to the required 350 SHELL, so funding is not the blocker.

• Recovery records the former mainnet endpoint https://mainnet.ackinacki.org/graphql.
• Official dexdo 0.2.1 with official mainnet manifest 4.0.36 passes doctor; that manifest resolves https://dd-mainnet.ackinacki.org.
• Re-running the original note deploy --recovery with current CLI refuses before a wallet submission: recovery file does not match this deploy request ... different wallet/endpoint/nominal/token-type.
• note recover cannot help because it correctly requires an already created pn_address; this recovery has none.

Expected canonical recovery support: after current-manifest doctor and an exact wallet/nominal/token-type match, allow a narrowly validated endpoint migration or compatibility resume for the same fenced voucher. It must prove whether the original voucher was accepted, must never create a second voucher/payment, and must persist a redacted receipt before any deployPrivateNote continuation. Hand-editing the recovery endpoint is not acceptable.