refactor(conformance): the Python runner is codeupipe pipelines

[JoshuaWink]

What

The Python conformance runner is now two codeupipe pipelines. It was 15 plain functions in runner.py.

This PR is on top of #15, which is on top of #14. Merge them in that order.

The pipelines (conformance/runners/python/case_runner/)

RunCasePipeline plays one case on one target:

Step	What it does
ParseTargetFilter	What the name of the target means: compiled or not, async or not, the layout, with State or not
WritePredicatesFilter	The Predicates of the case, as real classes in a module on disk
BuildPipelineFilter	The pipeline of the case, and the name that the case gives each step label
AttachRecordHookFilter	The Hook that records the lifecycle, for a case that asks for it
Valve, compiled: ExportFilter	Compiles the pipeline and imports the package from disk
Valve, not compiled: RunDynamicFilter	Runs it with run or run_async
Valve, compiled: RunCompiledFilter	Runs the compiled function
NameStepsFilter	Gives each step in the result the name of the case
FinishResultFilter	The id of the case and what its Taps recorded

BenchScenarioPipeline times one scenario. It uses the first three steps and ExportFilter again, then MakeRunFunctionFilter and MeasureFilter.

RunEachCaseFilter and BenchEachScenarioFilter go through the cases. A case that the target cannot express is reported, and the next case still runs. runner.py is the command line: 12 lines.

How it was checked against the old runner

• On each of the 5 Python targets, both runners got all 30 cases and 7 more that were made to fail (a word that the runner does not know, an empty nested pipeline, Hooks with a failure). The reports are the same, byte for byte.
• A name that is not a target gives the same message and the same exit code.
• In the timing mode, the outputs and the refusals are the same on each target. The times are the same within the noise of a run: 6 more runs of one target, in both orders, gave ratios from 0.95 to 1.03.

The old runner is not in this PR. It was used for this comparison only.

Two things that the linter found in the new code

Writing the runner as primitives put it under the rules for primitives, and two of them fired on my first version:

• CUP-I002: two steps changed the result dict that they got from the Payload, in place. They now make a new dict.
• CUP-I003: RunDynamicFilter reads pipeline.state. Here that is correct: it is the State of the pipeline of the case, which the step ran, and that State is what the step reports. It has one allow-state-read comment that says so.

What it gains

• 15 allow-plain comments are gone. The pinned number in the repository self-check goes from 75 to 60.
• Each step has tests (tests/conformance/test_case_runner.py, 19 tests).
• scorecard/ used two functions of the old runner file. It now uses the same steps as the runner.

Checks

• Python tests: 554 pass, on Python 3.12 and 3.14.
• Conformance: 30 of 30 on each of the 7 targets.
• Both linters report nothing, in strict mode.
• Speed check: within its band.

Not in this change

• scorecard/ (29 comments) and conformance/bench.py (5 comments) are still plain code.
• The TypeScript runner.

🤖 Generated with Claude Code