Jumping on this

Two different problems, with a third bigger one underneath:

1. Not being able to increase the number is just because there have been no tags selected yet, and the number field has a maximum attribute bounded by that. So mostly a UX issue. Simple solution is to just allow any number to be entered here, not sure we need the upper bound. Or you can max out at the maximum selectable amount of tags, maybe.
2. Deleting the number causing a reset to any is caused by a definition loop where having a value in the number field is seen as the setting keeping the form in the min_matching state. Looks like we're trying to not mess with the CONDITION_OPERATOR enum, because that touches on a handful of unrelated uses. But, of course, when you then delete the min_matching number value, the form reverts to the default any state. I'll do a fix this in the current mold, but there should maybe be an expansion of the CONDITION_OPERATOR enum considered.
3. The promised third, bigger, problem is that I am not sure this filter even works correctly. Regardless of the min_matching value, the filter still seems to just work like the any condition.