fix: validate BFA channel metadata with Ethereum bridge context

[bandrivskiy]

Opening a Lightning channel funded with BFA can fail when the receiving node registers the asset's metadata. Transfer acceptance already validates the bridge history, but Wallet::save_new_asset() repeats validation with the default RGB VM. A funding consignment that includes a bridge mint requires the cea instruction and Ethereum event context, so this second validation rejects an otherwise valid consignment with an AluVM script failure. Normal on-chain receipt uses a separate path that already validates BFA with Ethereum context.

Use the existing validate_consignment_for_schema() helper in save_new_asset(). For BFA, it supplies the bridge's FundsIn events and enables IssuedAmountCheckExt; other schemas continue through ordinary RGB validation. Pass an empty assumed_events slice so metadata registration validates against observed bridge events without assuming pending deposits. Extend the bridge mint regression test to register the asset in a fresh wallet and assert its BFA schema and known circulating supply.

Validation:

• On the branch merged with current dev (6e48f22), passed cargo clippy --lib --workspace --all-features --all-targets -- -D warnings, plus the no-default-features, electrum-only, and esplora-only library configurations.
• cargo fmt --all -- --check and git diff --check passed.
• Before the dev merge, passed the local rgb-lightning-node regtest/Anvil lifecycle test with 840e22a and the companion Lightning changes: bridge mint, SDK and REST channel funding, payments across two channels, restart, cooperative and force close, and an on-chain burn with verification of the recipient in the exported proof.
• The standalone rgb-lib regression case (wallet::test::bridge::success) compiles; its execution and the full test suite are pending GitHub Actions.