The PR description doesn't seem accurate. Is this really a good idea for 3.12 (3.12.0 rc3 or 3.12.1)? Do we have a good handle on potential fallout from adding this workflow? Is the benefit of running on 3.12 worth the potential disruption?

My opinion: I don't think it's crucial at all that this gets into 3.12.0; I'd certainly be fine with it being delayed until 3.12.1. However, I don't see it as a particularly risky change, so I also don't think there'd be any harm in it going into 3.12.0.

What this PR does

It adds a workflow that runs ruff in CI on Lib/test/. Only a single ruff rule is enabled, F811. The rule flags names that appear to be redefined before being used in the same scope. In my experience, the number of false positives from F811 is very low, so I think there's very low risk of disruption.

Why adding this CI check is useful

This is useful for CPython, in that it means that the rule detects unittest.TestCase subclasses where two or more test methods have the same name. This is an issue that's cropped up repeatedly for CPython, where we don't realise that tests are being silently skipped, because they're being overridden before they're ever being run.

Why I think it's good to backport this PR to 3.12 (but not necessarily 3.12.0)

We've had lots of situations in the past where core developers have been pretty confused due to CI setups being subtly different between the main branch and the various bugfix branches. Where possible, and where it's low-risk to do so, I think it's generally useful to keep the branches in sync on this kind of thing.