Bug: `thresh(k, pubkeys[21])` policy does not compile for `k < 3`

<sanket1729> Yup, that is indeed a bug. The issue is for k = 1 to 3, we pick sub-compilations for children optimally. All pk() are mapped to pkh() with a likely wrapper and that exceeds the max-opcount for 200 
20:01 <sanket1729> The correct compiler logic would pick optimal compilation for children keeping tract of possible op-counts. 
20:02 <sanket1729> But that would lead to even slower compiler with high space requirements. 
20:03 <sanket1729> For k = 4, the probabilities for leaf are high, so their optimal compilations are mapped correctly under the MAX_OP_COUNT
20:03 <sanket1729> sipa: Do you have any inputs?
20:04 <jeremyrubin> "taproot fixes this"
20:06 <sipa> lol
20:06 <sipa> yes
20:06 <sanket1729> Maybe, if the optimal greedy compiler fails. We should build another version that minimizes the op-counts but still constructs some miniscript. 

Should Taproot or us fix this ?

Start by reproducing the thresh(k, pubkeys[21]) case for k < 3 and trace the compiler's handling of pk(), pkh(), and MAX_OP_COUNT. Review the discussion of optimal child compilations and Taproot, then determine whether rust-miniscript or Taproot owns the fix. Done means the responsibility is resolved and the affected policy compiles within the op-count limit.