fix(ci): wait for the lagging job list before judging full-queue evidence

Problem

Merge-queue run 41120003339 (PR #1214, queue SHA 6a8383f7) had every lane green, yet pr / required failed with Required job did not complete successfully at the exact SHA from scripts/ci_evidence.py.

emit() reads the run-attempt job list a few seconds after the last lane finishes. That list lags a job's own completion: 38 s after ci / ci / status had completed (the single-job endpoint reported completed / success), the job list still reported it as in_progress, so successful_jobs() rejected the run and the queue dropped the PR.

Change

• settled_jobs() re-reads the job list, bounded to twelve reads ten seconds apart, until every expected job reports completed, and logs which jobs it is waiting on.
• emit() judges the last read exactly as before: successful_jobs() still rejects incomplete, skipped, cancelled or failed required jobs, so the bound only turns a transient lag into the existing failure instead of hiding it.
• reuse() is unchanged; it already requires the producer run itself to be completed.

The wait stays well inside the aggregate's 10-minute timeout (at most 110 s). Because policy_digest() covers scripts/, this change invalidates reuse of queue evidence produced before it, which is the intended behaviour for any validation-policy change.

Tests

Two regression tests in tests/scripts/test_ci_evidence.py: one reproduces the lag (two in_progress reads, then settled) and asserts the evidence is accepted after two sleeps; one asserts the read count is bounded and that a job that never settles is still rejected.

• uv run --locked pytest tests/scripts/test_ci_evidence.py -q → 76 passed
• uv run --locked pytest tests/tooling/test_pr_validation.py -q → 182 passed
• uv run --locked ruff check / ruff format --check clean on both files