Reassignment after mandatory re-extension strands UTXOs for both owners

[icellan]

Mandatory transaction re-extension exposes a reassignment regression: changing a frozen UTXO to a different owner updates its commitment but does not persist the replacement locking script. Re-extension retrieves the original script, so the new owner's signature fails. The original owner's signature passes that script but the recomputed commitment differs from the stored reassigned commitment. Neither owner can spend the output after maturity.

This affects the ownership-changing alert/confiscation and RPC flows on main after 3e26a5d2fad9e22cf2ea4f40ee4babf362ac5d28 and release/v0.15 after c7682127778565279fe51369194a88e4925dedd6. The existing v0.15.9-beta-1 tag points to 9272b80c9259d00fd51eb8f66ee658a46adb940a, before that release-branch merge.

Reproduction:

1. Store and mine an output locked to Bob.
2. Freeze it and call ReAssignUTXO with a commitment to Charles's script.
3. Advance beyond the reassignment maturity height.
4. Submit a Charles-signed spend with the replacement script in its extended fields: script validation rejects it.
5. Submit a Bob-signed spend: the store rejects it with UTXO_MISMATCH.

Operator impact: successful reassign/alert processing does not establish spendability. Avoid ownership-changing reassignment until this is resolved. There is no documented, validated recovery procedure; do not assume that re-freezing and restoring the original commitment is portable. SQL freezing locates by outpoint without checking the supplied commitment, while Aerospike checks it.

Required follow-up:

• Provide an authoritative replacement-script source and validation support without trusting submitter-supplied extended fields.
• Restore new-owner spending after maturity and reject the old owner, with SQL and Aerospike end-to-end coverage.
• Define failure/Processed reporting and recovery for already-reassigned outputs.
• Resolve the maturity-setting discrepancy: SQL honors utxostore_reassignedUtxoSpendableAfterBlocks, while Aerospike currently uses the fixed 1,000-block constant.
• Add verified operator guidance and release notes when support is restored.

The SQLite smoke test in #1721 (backport #1722) documents and pins the current limitation. Its same-owner reassignment is a control for maturity, not proof that ownership-changing confiscation works. Those PRs remain tests/documentation only.

[icellan]

Review follow-ups from PR #1726 for the production reassignment work:

• Decide how the RPC and confiscation-alert entry points should refuse ownership-changing reassignment until replacement scripts can be persisted and validated. They currently apply it and report successful processing. The alert path derives the script but does not persist it.
• Review RPC authorization: reassign is currently callable with limited credentials. SQL reassignment and freezing also select by outpoint without checking the supplied old commitment; Aerospike checks it.
• Align the maturity setting and errors across backends. SQL honors positive configured delays, with zero falling back to 1,000; Aerospike always uses 1,000. Immature SQL reassignment spends return ErrTxLocked, while Aerospike returns ErrUtxoFrozen.
• Define input-validation and audit expectations. The RPC zero-pads short hashes and casts the output index to uint32 without a sign check. SQL does not keep reassignment history; Aerospike appends to its reassignments bin.

PR #1726 documents these limitations and strengthens their test coverage. Runtime reassignment guards, persistence/recovery, and backend behavior changes remain in this follow-up under the agreed tests/documentation scope for reassignment.