whole issue push

[sbn20241]

This PR is for context and review only — not intended to be merged as-is.

The test fixtures capture a snapshot of the wallet and hub state from our Signet multisig setup. That lets anyone replay and see the issue we hit in practice, without running the full live flow.

What we saw: a PSBT was signed outside the party wallet — through a separate rgb-lib service — and rgb-lib’s own checks (inspect_psbt, pre-ACK validation, finalize_psbt) did not flag it as invalid. The transfer could move forward even though the signing path did not match what the hub recorded.

We added two regression tests for cases that look suspicious to us.

The first is the clearer one: signatures from keys that are not part of the multisig at all (one valid cosigner signature plus foreign ones). We expect rgb-lib to reject this at every step. Today it mostly does not — only finalization fails.

The second comes from hub op #5: the two cosigners were effectively swapped — party-2’s response was signed with a different cosigner’s key than we expected. We are not sure this is a serious security bug on its own; for a 2-of-3 script the signature set can still be valid. But it does make it harder to reason about who actually signed and who the hub acknowledged, especially if signing happens outside the wallet app. We track this case too so the behavior stays visible.

Both tests are written to fail until rgb-lib rejects bad PSBTs earlier in the pipeline. A failing test means the gap is still there; it is not a broken test. Run cargo test --lib foreign_one_valid -- --nocapture for foreign keys and cargo test --lib op5_wrong_cosigner -- --nocapture for the swapped-cosigner case.

How to run

From the repo root:

cargo test --lib foreign_one_valid -- --nocapture
cargo test --lib op5_wrong_cosigner -- --nocapture