Release: baseline + quarantine tooling to make the sharded suites a gate (Phase 1.3/1.4)

[PurHur]

Follow-up to #24445. Sharding made VMTest runnable; this makes it a gate.

Why runnable isn't enough

Neither suite is green — VMTest carries ~400 pre-existing failures — so "did it fail?" is always
yes and carries no information. The gate is the set difference of failing case names against a
committed baseline (AGENTS.md §2).

script/compliance-baseline.sh --collect --suite=VMTest   # shards -> test/compliance/baselines/
script/compliance-baseline.sh --diff    --suite=VMTest   # current shards vs committed baseline

Two guards, both validated by making them fire

guard	why it exists	verified
INCOMPLETE	diffing 3 of 24 shards reports every unrun case as newly-passing — it reads as a large improvement	"INCOMPLETE — 1 of 400 shards have results", exit 2
MIXED	results from different --shards=N runs cannot be unioned; some cases double-count, others vanish	"MIXED shard widths present (16,8)", exit 2

I test guards by breaking them because a guard that cannot fail is the recurring failure mode in this
repo — including in my own shard-compliance.sh last iteration, where grep -c … || echo 0
silently disabled the zero-executed check.

The quarantine file is deliberately empty

Phase 1.4 names hrtime_*, proc_get_status_basic, interface_abstract_static_call and
dnf_return_type_error as suspected flaky. Suspicion is not measurement. Quarantining a case on
reputation hides any real regression in it, so each needs two full runs of one commit showing it on
one side and not the other before being listed.

The file documents that policy, and that entry is a bug to fix rather than a resting place.

Quarantined names are excluded from both sides of the diff, because a flaky case in a baseline
manufactures phantom regressions. That has already cost real time twice: an e08_spread
"regression" that turned out to be 17/30 vs 17/30 noise, and two sweeps of the same master
disagreeing about k06/m04 (#24388).

No baseline data in this PR

The full 24-shard VMTest run takes ~2–3 h on this box — one container at a time, since concurrent
containers sharing the bind mount corrupt each other's caches — and is still running.

The tooling refuses to produce a baseline from partial results, which is exactly the behaviour
that makes it trustworthy. The data lands in a follow-up once a complete run exists, and ideally
after a second run confirms which cases flip.