With bitcoin-cli, I [successfully spent](https://bitcoin.stackexchange.com/questions/123669/how-to-spend-a-multisig-descriptor-wallet-transaction-with-bitcoin-cli) (broadcast, was accepted by the regtest node and then mined) a tx spending two 1-of-2 script-path multisig outputs.

The spent prevout descriptors were:

`tr(<unspendable_bip341_key>,multi_a(1,<even-parity-33-byte-key1>,<odd-parity-33-byte-key1>))`

After the spending transaction was mined into a block, I viewed the multisig script: `bitcoin-cli -regtest decodescript <tapscript>` where `<tapscript>` was the penultimate element of the input witness stack. I got:
```json
{
  "asm": "<x-only-32-bytes-of-key1> OP_CHECKSIG <x-only-32-bytes-of-key2> OP_CHECKSIGADD 1 OP_NUMEQUAL",
  "desc": "raw(<hex>)#<checksum>",
  "type": "nonstandard"
}
```

My questions are:

 1. Apparently, it's [expected](https://bitcoin.stackexchange.com/a/117520/137810) that the parity (first `0x02` or `0x03`) byte is dropped from the 33 byte keys that I put in the descriptors, when I created the output. The keys become 32-byte x-only keys. When spending and verifying this, how does it recover the parity information, it appears to be lost in the decoded tapscript?
 2. Why does `decodescript` return `nonstandard`? My core version is v0.25, and the spent prevout was [created](https://bitcoin.stackexchange.com/a/123690/137810) by its bitcon-cli.
 3. `btcdeb` [refuses](https://github.com/bitcoin-core/btcdeb/issues/154) to validate this script. This [could be due to](https://github.com/bitcoin-core/btcdeb/issues/154#issuecomment-2244081180) `btcdeb` being on the v0.24 still, however.