CI: cache Trivy vulnerability DB across runs DB fetch is an unguarded dependency in the release path

## Summary

Every run of the `scan-image` job in `deploy.yml` downloads the Trivy vulnerability database
from scratch (~108 MiB, measured ~35s). The DB is cached within a job three scan steps
share one fetch but nothing persists it across runs.

## Impact

This is an availability problem, not a latency one.

`scan-image` gates `deploy`. So every production release depends on a third-party download
succeeding at release time. A network blip, an upstream rate limit, or a registry incident
fails the fetch, fails the job, and blocks the deploy.

The failure is also misleading. A DB-fetch failure surfaces as the security gate failing,
which reads as "a vulnerability was found" to whoever is on the release. Expect an hour lost
to diagnosing the wrong thing.

Latency is the secondary benefit; removing the hard dependency is the point.

## Proposed fix

Persist the Trivy cache directory across runs with `actions/cache`, so a failed fetch can
fall back to the last-known-good DB rather than failing the job.

`trivy-action` supports pointing at a cache dir. Design decisions to settle when this is
picked up:

- **Refresh cadence** — how stale is acceptable before a fetch failure should be fatal
- **Cache key** — date-based, or key-on-miss with a restore-key fallback
- **Stale-hit visibility** — a stale DB must be reported in the step summary, since a
sufficiently old DB silently weakens the gate. Falling back quietly is its own failure mode.

The default posture should be: fetch failure degrades to a stale DB with a loud warning,
rather than blocking the release.

## Why this wasn't in the supply-chain PR

The cache-key design above is a small but real decision surface, and that PR already carries
the `cargo-auditable` change, the build assertion, the scan job, and the deploy gate. Folding
this in would have made it harder to review the parts with production blast radius.

## Acceptance criteria

- [ ] Trivy DB persists across workflow runs
- [ ] A DB-fetch failure degrades to the cached DB instead of failing the job
- [ ] Stale-DB use is visible in the step summary with the DB age
- [ ] Cache staleness bound is documented in `docs/supply-chain.md`
- [ ] Workflow passes `yamlfmt --lint` and zizmor review

eta: 2days

Start in `.github/workflows/deploy.yml` on the `scan-image` job and inspect how `trivy-action` is invoked. Add cache persistence around the Trivy DB path (likely via `actions/cache`) with a clear key/restore-key strategy and configure behavior so fetch failures can fall back to a cached DB. Then update `docs/supply-chain.md` with the cache staleness policy and stale-hit warning behavior, and finish by running `yamlfmt --lint` plus a `zizmor` review; done means workflow linting/review pass and the deploy scan path documents and warns on stale DB use.

Escrita pelo modelo de indexação a partir do texto da issue.