Run the python suite in CI as a ratchet

[bjmeetsfo]

The python suite is not run by CI. .github/workflows/ has rust-ci, oss-readiness, governance
and auto-approve, and none of them invoke it.

That is how nine test files which could not even import sat here unnoticed — every test in them
errored on import, and nothing reported it. (Removed in #149.)

Why a ratchet rather than a gate

Making the suite blocking today would mean fixing 131 pre-existing failures before anything
else could land. This records what fails now in tools/python_suite_baseline.json and fails only
when a change adds a failure. Existing failures stay visible, and the baseline shrinks as
they are fixed — rerun with --record to bank the wins. The job also prints what got fixed, so
progress is visible without anyone hunting for it.

Why it re-runs the whole suite to confirm

Several tests here fail in one run and pass in the next — order-dependent, or racing background
work. A ratchet that trips on those is a ratchet nobody keeps green, so a new failure must appear
in two full runs before the build fails. The second pass only runs when something new showed
up.

The cheaper-looking option does not work. Filtering with -k still imports every module, so
unrelated import errors land in the output and there is no reliable way to tell "this test
failed" from "the suite could not load". Measured: an isolated run of a passing test
reported 8 errors.

Verified

clean tree                          -> "no new failures."          exit 0
with a deliberately failing test    -> NEW failures (1):           exit 1
                                          test_ratchet_canary_deliberate_failure

The canary run also shows the flake filtering working: the first version of this script reported
test_background_worker_refreshes_dirty_nodes_and_embeddings alongside the real failure, and the
two-pass version reports only the real one.

Two bugs worth naming

The first cut returned bool(generator) from its isolation check. A generator object is always
truthy, so every new failure would have been treated as real and the flake filtering silently
defeated — the check would have looked like it worked. The second counted any failure line
rather than lines naming the target test, which was always true for the reason above.

Both share a shape worth watching for: a guard that cannot fail is indistinguishable from a
guard that passes. That is also the argument for the canary test above — a ratchet nobody has
seen fail is not known to work.