Monitor: report a version only when its final tarball exists; dedupe failure issues

[ronaldtse]

Fix the release monitor's daily 3.15.0 false positive + failure-issue dedupe

The scheduled release monitor has failed daily since 2026-09-03 (FAIL 3.15.0: HTTP 404 from https://www.python.org/ftp/python/3.15.0/Python-3.15.0.tar.xz; runs 34686192863, 34586984384, …) and filed a fresh issue per run: #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13. Those duplicates are left open for the owner to close with a pointer here.

Root cause (the actual code path)

Upstream creates https://www.python.org/ftp/python/<v>/ with the line's first pre-release: ftp/python/3.15.0/ has served Python-3.15.0a1 … 3.15.0b2 for months while the final Python-3.15.0.tar.xz still 404s. Tfs::PythonReleases::DIR_FORMAT matches exact X.Y.Z/ directory hrefs, so 3.15.0/ parsed as a normal release; new_versions reported it (latest of an untracked in-window line); --onboard then hard-failed on the tarball 404 and the workflow filed a new issue every day — with no dedupe. The old code (and the old fixture comment) assumed pre-releases live in suffixed directories (3.15.0a1/); upstream actually stages them inside the final version's directory.

Detection side (tools/lib/tfs/)

• HttpGet.exists?(url) — a HEAD probe with redirect following: true on 2xx, false on a definitive 404, named HttpGet::Error on anything else (a probe that cannot decide never silently answers). The redirect loop is now shared with .body via a private terminal/2; .body's behavior and messages are unchanged.
• PythonReleases.new(html, tarball_probe:) — injectable probe, default Tfs::HttpGet.method(:exists?) (the ReleaseCopier fetcher: pattern). new_versions selects candidates exactly as before, then keeps only those whose final tarball answers 200. A 404 means simply not reported — never an onboard attempt, never an issue — with a stderr note (python 3.15.0: skipped — the final tarball is not published yet (…)) so the daily run's log says why. Pre-release-suffixed entries (3.15.0a1/) never parse, as before.

Issue dedupe side (.github/workflows/release-monitor.yml)

The failure step now searches open issues for the exact title (gh issue list --state open --search 'in:title "<title>"' --json number,title, exact-match filtered with jq) and, on a hit, comments the recurrence date plus the fresh monitor-result.json detail instead of filing a duplicate. Title format, issue body, and the PR-on-success path are unchanged.

Specs

spec/fixtures/python_index.html now models the real upstream layout: a 3.15.0/ staging directory beside the never-parsed 3.15.0a1/. spec/tfs/python_releases_spec.rb stubs the HTTP layer the way release_copier_spec.rb does (an injected lambda) and covers: final tarball 404 → not reported (+ the stderr note asserted); final tarball 200 → reported; suffixed pre-release entries never parsed; no candidates → the probe is never called. The dedupe helper is workflow-side bash/jq, not script-side, so it carries no rspec case (its jq filter was verified locally against sample gh issue list --json output: exact-title hit picks the open issue, no hit falls through to create).

Evidence (run in this branch)

• bundle exec rspec — 101 examples, 0 failures
• bundle exec tools/validate_manifests — OK all manifests valid against schema/
• Live end-to-end: tools/monitor --detect against the real python.org index now prints {"version":[]} with the 3.15.0 skip note on stderr (previously it reported 3.15.0, which produced the daily 404 onboard failures).
• Workflow YAML parses clean.