test(discovery): synthesize a scored run without a guest

[pengyuzhang]

Stacked on #60.

The scoring engine is built before any VM exists, so it needs input before any VM exists too.

What it produces

A run directory shaped exactly like one a real guest leaves behind — before.json, after.json, manifest.actual.json, canaries.json — built from the manifest, with defects injected on purpose.

$ python3 -m tests.tools.synthesize --os linux --out runs/whatever
wrote runs/whatever: 70 assets

The injected defects exercise every outcome the scorer can produce: a miss, a duplicate spanning several entries, an invention a negative control explains, and one nothing explains. A fixture containing only successes tests nothing but the happy path.

--clean injects nothing, which is how the "a correct collector scores a clean sheet" case gets exercised — the half that is easy to forget, and the half that decides whether the instrument raises false alarms.

This is not a captured run

Every directory it writes carries "synthetic": true in its own metadata, and a later PR asserts that it does. A synthetic run proves the scorer computes what we think it computes. Only a real one says anything about the collector.

recorded/ is load-bearing

Runs checked in there become the scoring engine's own fixtures: change the scorer, replay every recorded run, see exactly which verdicts moved. That property is what lets the scoring work happen at all before there is a VM to run against, and what keeps it honest afterwards.

The checked-in synthetic-linux/ is byte-for-byte reproducible from the manifest:

$ python3 -m tests.tools.synthesize --os linux --out /tmp/regen
$ diff -r /tmp/regen tests/recorded/synthetic-linux
(no output)

Verification

$ python3 -m unittest discover -s tests -t . -q
Ran 20 tests in 0.010s
OK