This is closely based on test/functional/wallet_miniscript_decaying_multisig_descriptor_psbt.py both in code and concept. It builds the same "decaying" multisig that starts as 4-of-4 and decays to 3-of-4, 2-of-4, and finally 1-of-4 at each future halvening block height, but as a Taproot output, combining Taproot, Miniscript, and MuSig2 in a single descriptor of the form tr(musig(key_1,key_2,key_3,key_4),thresh(4,pk(key_1),s:pk(key_2),s:pk(key_3),s:pk(key_4),sln:after(t1),sln:after(t2),sln:after(t3))). While every signer is available the 4-of-4 is spent through the Taproot key path using a MuSig2 aggregate of the participants, which is the cheapest and most private spend, while the Miniscript script path is a fallback used only when a key becomes inaccessible, so a lost key never permanently strands the funds and the key path stays available even after the multisig has fully decayed. As with the wsh version the signers are plain single-key wallets and the multisig is watch-only, so everything needed to sign (including the MuSig2 participant pubkeys) is carried in the PSBT and signers never import the multisig descriptor. It serves as integration testing for Taproot, Miniscript, and MuSig2 descriptors working together, and like the wsh test is meant to be documentation as much as a functional test, so it is kept as simple and readable as possible.
Note: this thresh-based design has BIP110-invalid script-path spends. sln:after compiles to OP_IF in the tapscript leaf (the key-path spend is unaffected). I implemented an alternative that avoids this by splitting the decay into separate timelocked multi_a tapleaves (no OP_IF) in e0482ec. It's a quick, less-thoroughly-tested implementation, but I wanted to present it in case reviewers prefer that approach.
