fix(bounty): refuse a stable torn leaderboard/reports pair

[echobt]

Summary

Follow-up to #204. Greptile P1: two consecutive equal pair-reads only prove each route was still. A backend that always serves leaderboard revision A beside reports revision B produces the same mixed composite twice and would have been signed.

Two Cortex-side pins, neither requiring a new backend endpoint:

1. /leaderboard valid_count must match the valid rows on /reports (snapshot_halves_agree).
2. When both routes carry a publication token (revision / snapshot_id / etag in the JSON envelope, or HTTP ETag), those tokens must be equal.

A stable torn pair is BackendError::Mismatched and the emitter burns (covers E with ChallengeInternal). A moving feed that never holds still is still Inconsistent.

relearn-eval stays unpinned; sha256:cbc4bbb8 is not re-pinned.

Greptile

• Greptile has reviewed this PR; findings are fixed or answered
• If the bot was silent, I commented @greptileai review

Fixes the P1 on #204 (crates/bounty-challenge/src/backend.rs). T-Rex's stable torn harness (leaderboard A valid_count=1, reports B) is the mismatched_publication_tokens case when the envelope carries revision.

Test plan

• cargo test -p bounty-challenge --test emit_fail_closed
• cargo clippy -p bounty-challenge --all-targets -- -D warnings
• GitHub CI fmt · clippy · test · deny · xtask

Naming

I did not rename BASE_* environment variables, deployed host paths (/opt/base, /run/base, …), GHCR baseintelligence/base package names, or base-*-v1 cryptographic domain tags.

  

[greptile-apps]

Greptile Summary

This change adds fail-closed reconciliation between bounty leaderboard and report snapshots before publishing an epoch. A coherent pair of responses can still be rejected when neither payload provides a shared publication token and the routes return different HTTP ETags: the emitter burns the epoch instead of signing and scoring the valid snapshot. This should be corrected before merge.

Confidence Score: 4/5

Not safe to merge until cross-route publication-token comparison stops treating independent HTTP ETags as a shared revision identifier.

A focused end-to-end reproduction exercised coherent route payloads with distinct stable ETags and directly observed snapshot rejection followed by an epoch burn.

Files Needing Attention: crates/bounty-challenge/src/backend.rs needs attention; crates/bounty-challenge/src/emit.rs propagates the resulting rejection into the burned-epoch outcome.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding by validating the focused loopback Axum path and capturing the relevant validation outputs.
• T-Rex produced an additional proof for the same P1 finding, including the focused validation command output and related validation artifacts.
• T-Rex ran the general contract validation for the bounty emitter, observed exit code 0, documented the Mismatched HTTP ETag handling, and traced the burn path in the emitter code.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(bounty): mismatch envelope revision ..." | Re-trigger Greptile}

[greptile-apps]

Route-specific ETags reject coherent snapshots

publication_token falls back to each response's HTTP ETag, and publication_tokens_agree then requires the leaderboard and reports tokens to match exactly. ETags are opaque validators for an individual response representation, so coherent routes can legitimately use distinct stable ETags when neither JSON envelope provides a shared revision token. The snapshot is consequently treated as mismatched and the emitter burns the epoch instead of signing and scoring it. Compare only an explicitly shared publication revision across routes, or retain ETag provenance and avoid comparing ETags from different resources.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Artifacts

Focused loopback Axum validation source

• The exact temporary test source starts a loopback Axum backend with matching leaderboard/report data, no JSON publication tokens, and distinct ETag headers; it captures the reproducer setup and its takeaway.

Focused validation command output

• The executed focused cargo test exited 0 after proving the coherent ETag-divergent feed was rejected and the emitter burned the epoch; the takeaway is that the hypothesis reproduces end to end.

Complete bounty emitter integration-suite output

• The executed full emit_fail_closed integration suite exited 0 with 10 passing tests, including the focused reproducer; the takeaway is that the reproduction is compatible with the surrounding integration behavior.

Validation-only test diff

• The captured diff shows the loopback ETag reproducer added only to the integration test file and no product-code edits; the takeaway is that production behavior was observed without changing product code.

Focused validation source capture

• The captured source log contains the exact focused loopback Axum reproducer used for validation; the takeaway is that the executed test setup is fully inspectable.

Focused loopback Axum validation source

• The exact temporary test source starts a loopback Axum backend with matching leaderboard/report data, no JSON publication tokens, and distinct ETag headers; it captures the reproducer setup and its takeaway.

Focused validation command output

• The executed focused cargo test exited 0 after proving the coherent ETag-divergent feed was rejected and the emitter burned the epoch; the takeaway is that the hypothesis reproduces end to end.

_{Ran code and verified through T-Rex}