Scheduled re-scan of the deployed image digest

Follow-up to #388.

`docs/supply-chain.md` names this as the single largest gap in the container supply-chain pipeline, and it is the common cause of three others.

## Problem

`.github/workflows/deploy.yml` triggers only on pushes to `main`, on release tags matching `v*.*.*`, and on manual dispatch. The image scan therefore runs a handful of times a month, always tied to someone shipping something. Three consequences follow:

1. **Post-merge advisories are not detected.** A newly published RustSec advisory affecting a shipped crate first surfaces whenever someone next cuts a release. This is the capability usually claimed for container image scanning, and the pipeline does not currently deliver it. `cargo-audit` / `cargo-deny` / `cargo-vet` cover the source tree on every PR, but only for commits that exist — an advisory published against an unchanged lockfile triggers nothing.

2. **`expired_at` lapses surface as blocked releases.** Once the gate blocks (#409), an expiring exception in `.trivyignore.yaml` fires at the only moment this pipeline runs — during a release — rather than as advance warning. Today the guidance in `docs/supply-chain.md` is "prefer expiry dates that do not fall close to a planned release", which is a workaround for this gap rather than a practice worth keeping.

3. **Release-tag scan results have no durable sink.** The SARIF upload is branch-gated to `main` on purpose: code scanning files an analysis against a ref, and alerts for `refs/tags/*` are not surfaced in the Security tab's branch view, so uploading there would succeed into a place nobody reads. That leaves release runs with results only in run artifacts, which expire with artifact retention.

## Proposal

One scheduled workflow that:

- resolves the image digest currently deployed to production,
- scans it with the same severity floor and the same `.trivyignore.yaml` as `scan-image`, so the scheduled result and the release-time result mean the same thing,
- uploads SARIF against the default branch, so findings land somewhere durable and readable regardless of which ref produced the image,
- opens or updates an issue on failure rather than only turning a run red.

The last point matters: an unmonitored scheduled job that fails silently is indistinguishable from one with nothing to report, which is the same trap the rest of this pipeline is built to avoid.

## Acceptance criteria

- [ ] A scheduled workflow scans the deployed digest on a cron.
- [ ] Scan configuration is shared with, or provably identical to, `scan-image`.
- [ ] Results are visible outside the run that produced them.
- [ ] A failure produces a notification a maintainer actually receives.
- [ ] The Known Gaps entries in `docs/supply-chain.md` that this closes are updated: post-merge advisory detection, `expired_at` timing, and the release-tag SARIF sink.

## Related

- Parent: #388
- Gate enablement: #409
- Ignore-entry hygiene: #406
- Source analysis: #380
- Production readiness EPIC: #141
- Local/remote CI parity: #316

Read `.github/workflows/deploy.yml` and the existing `scan-image` workflow path to mirror current Trivy invocation and `.trivyignore.yaml` handling. Review `docs/supply-chain.md` Known Gaps and update only the three listed items once the workflow is in place. Add or modify a workflow under `.github/workflows/` with a cron trigger that scans the deployed digest, uploads SARIF to default-branch context, and raises/updates an issue on failure. Validate by running it manually once, checking Security-tab visibility, and confirming issue creation plus docs updates match acceptance criteria.

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