ruff

066239fe - [red-knot] improve type shrinking coverage in red-knot property tests (#15297)

[red-knot] improve type shrinking coverage in red-knot property tests (#15297) ## Summary While looking at #14899, I looked at seeing if I could get shrinking on the examples. It turned out to be straightforward, with a couple of caveats. I'm calling `clone` a lot during shrinking. Since by the shrink step we're already looking at a test failure this feels fine? Unless I misunderstood `quickcheck`'s core loop When shrinking `Intersection`s, in order to just rely on `quickcheck`'s `Vec` shrinking without thinking about it too much, the shrinking strategy is: - try to shrink the negative side (keeping the positive side the same) - try to shrink the positive side (keeping the negative side the same) This means that you can't shrink from `(A & B & ~C & ~D)` directly to `(A & ~C)`! You would first need an intermediate failure at `(A & B & ~C)` or `(A & ~C & ~D)`. This feels good enough. Shrinking the negative side first also has the benefit of trying to strip down negative elements in these intersections. ## Test Plan `cargo test -p red_knot_python_semantic -- --ignored types::property_tests::stable` still fails as it current does on `main`, but now the errors seem more minimal.