ci: run integration tests against live Tempo container, remove mocks

[brendanjryan]

Summary

Run integration tests against a real Tempo devnet + Redis in CI. Replace mock-based charge tests with integration tests.

CI Changes

• Add integration job that starts devnet + Redis via docker compose up -d --wait, runs pytest -m "integration or redis" (fixes gap where Redis integration tests were not exercised in CI)
• Added to ci-gate required jobs

Tests Added (integration)

• test_verify_hash_replay_rejected_with_store
• test_verify_hash_replay_allowed_without_store
• test_verify_hash_store_records_on_success
• test_verify_hash_tx_not_found
• test_verify_external_id_propagated

Tests Removed (mocks)

• 5 mock tests from test_tempo.py (now covered by integration)
• Deleted test_stores_redis.py entirely (all 8 tests covered by test_stores_redis_integration.py, now run in CI via redis marker)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eb8836b120

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use one Tempo tag for cache and runtime image

The integration job caches/pulls ghcr.io/tempoxyz/tempo:${TEMPO_TAG} here, but docker compose up starts the Tempo service from docker-compose.yml (ghcr.io/tempoxyz/tempo:v1.5.2), so this cached image is never used. In practice this adds unnecessary registry traffic and cache churn, and CI is not actually exercising the image selected by TEMPO_TAG, which can hide regressions when the intended test target changes.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Pin integration actions to immutable SHAs

This job switches to floating action tags (actions/checkout@v4 and astral-sh/setup-uv@v4) while the rest of the workflow uses commit-pinned actions. Using mutable tags makes CI behavior non-reproducible and can unexpectedly break or change security posture when upstream retags/releases, so this introduces avoidable supply-chain and stability risk in a required gate.

Useful? React with 👍 / 👎.