scanner: reject duplicate BIP21 parameter keys (#63)

[Tyagiquamar]

In src/modules/scanner/implementation.rs, decode_onchain() parsed BIP21 URI parameters by collecting them directly into a HashMap<String, String>.

Per BIP-0021 specification, duplicate parameter keys in a URI make the URI invalid. Collecting into a HashMap directly silently dropped earlier duplicate keys, overwriting them with the last key-value pair.

This PR updates query parameter parsing to check for duplicate keys, returning DecodingError::InvalidFormat if duplicate parameter keys are present.

Fixes #63

Testing

• Added unit test test_duplicate_bip21_params_fails in src/modules/scanner/tests.rs.

[Tyagiquamar]

Hi, friendly ping for review on this PR when you have a moment. Happy to address any feedback. Thanks!

[Tyagiquamar]

Hi, just following up on this when you get a chance. The branch is up to date and checks are green. If it looks good from your side, it should be ready to merge. Happy to make any changes if needed. Thanks!

[pwltr]

Requesting changes for three issues:

1. The test suite will not compile as written. test_invalid_lightning_invoice_sync is synchronous but still uses #[tokio::test], whose target must be an async fn. Please either restore async or change the attribute to #[test].

2. This does not reproduce or fix #63. The issue input contains two concatenated bitcoin: URIs and therefore two ? characters. decode_onchain still splits on every ? and parses only parts[1], silently discarding parts[2]. The duplicate-key loop never sees the second URI. Please add the exact payload from #63 as a regression test and preserve/validate the complete query, for example by using split_once('?') before rejecting the embedded second bitcoin: URI.

This distinction is confirmed by both consumer apps. Android and iOS added matching January 19 workarounds that detect a second bitcoin: prefix in their scan and manual-entry paths, explicitly referencing bitkit-core#63. Those workarounds would still be required after this PR.

3. Rejecting every repeated query key is too broad. BIP 21 does not state that all duplicate keys are invalid, and its replacement BIP 321 explicitly permits repeated payment-instruction keys and requires accepting repeated unknown keys. Singleton fields such as amount, label, message, and pop should reject duplicates, but this needs a per-key policy rather than blanket HashMap rejection. BIP 321 also treats query keys as case-insensitive.

Relevant references:

• Issue payload
• BIP 321 duplicate-key rules and examples
• Android workaround
• iOS workaround