Abstract witness-tx verification behind a WitnessTx trait

[bitwalt]

Status

Internal review PR, staged on the KaleidoSwap fork. Not submitted upstream.
This exists so the patch can be reviewed as a clean diff before any
conversation with the rgb-protocol maintainers. Base branch
release/0.11.1-rc.10 is the pristine 0.11.1-rc.10 release; the diff
here is exactly the proposed change.

What this does

RGB's DBC verification path is typed against bitcoin::Transaction in
three places (dbc::Proof::verify, Anchor::verify, the Witness<D>
struct). That type cannot represent an Elements/Liquid transaction,
which is the one thing preventing RGB anchors from being verified on
Liquid.

This introduces a WitnessTx trait exposing exactly what the
verification path uses from a transaction:

pub trait WitnessTx {
    fn witness_txid(&self) -> [u8; 32];
    fn input_outpoints(&self) -> Vec<([u8; 32], u32)>;
    fn output_script_pubkeys(&self) -> Vec<Vec<u8>>;
}

dbc::Proof::verify and Anchor::verify become generic over
W: WitnessTx. The concrete TapretProof / OpretProof impls iterate
output_script_pubkeys() and dispatch to the existing ScriptBuf-level
ConvolveCommitProof / EmbedCommitVerify paths, which were already
chain-agnostic.

bitcoin::Transaction implements WitnessTx directly, so every
existing caller compiles and behaves unchanged.

Diff

207 lines across 8 files (1 new):

File	Nature
src/dbc/witness_tx.rs (new)	the trait + impl WitnessTx for bitcoin::Transaction
src/dbc/mod.rs	re-export
src/dbc/proof.rs	Proof::verify generic over WitnessTx
src/dbc/anchor.rs	Anchor::verify generic
src/dbc/tapret/mod.rs	tapret Proof impl iterates output scripts
src/dbc/opret/mod.rs	opret Proof impl iterates output scripts
src/seals/txout/witness.rs	verify_seal delegates to a shared WitnessTx-generic helper
src/validation/commitments.rs	combined DbcProof::verify generic

Testing

• The upstream test suite passes unchanged: cargo test --features rand is 45/45.
• No breaking changes for bitcoin::Transaction callers.
• rgb-ops, rgb-schemas, rgb-invoicing, and rgb-aluvm compile and
  run against the patched crate with no source modification.
• Exercised end to end against Liquid regtest (real RGB20 issuance +
  transfer, and a cross-chain Bitcoin/Liquid atomic swap) in a separate
  proof-of-concept repository.

Open questions for a future upstream discussion

1. Should WitnessTx live in rgb-consensus or a sibling crate?
2. Are the three methods the right minimum?
3. Should Witness<D> gain a generic tx parameter, or a generic sibling type?