OSV Scanner failing on main: sharp and adm-zip overrides have fallen behind published fixes

The weekly OSV Scanner run on `main` has been failing since 2026-09-14 ([run 34819144240](https://github.com/garrytan/gstack/actions/runs/34819144240)). The 2026-09-07 run was green, so this is fresh.

Two advisories, both in packages that reach the tree only through `package.json` `overrides`:

| Package | Pinned | Advisory | Severity | Fixed in |
|---|---|---|---|---|
| `sharp` | `0.35.0` (exact) | GHSA-rgj7-g3m4-5g8c, bundled libheif RCE | 8.9 HIGH | 0.35.4 |
| `adm-zip` | `^0.6.0` | GHSA-vwc7-r8mq-g2x9 / CVE-2026-76845, symlink-follow on extract lets a crafted archive overwrite files outside the target directory | 6.8 MEDIUM | 0.6.1 |

One detail worth flagging, because the scan output actively misleads here: the `adm-zip` advisory records a `last_affected` event rather than a `fixed` event, so the scanner table prints `FIXED VERSION = --` and the summary reads as though the finding is unfixable. It is not. 0.6.1 is published and sits outside the affected range; `POST https://api.osv.dev/v1/query` against `adm-zip@0.6.1` returns zero vulns, as it does for `sharp@0.35.4`.

### Real exposure is low, but that is not the interesting part

The only `sharp` consumer is `browse/src/screenshot-size-guard.ts`, which downscales full-page PNG screenshots and never decodes the AVIF or HEIF paths the libheif advisory covers. Nothing in the tree imports `adm-zip` at all; it arrives via `onnxruntime-node` under `@huggingface/transformers`. Both fixes are a one-line version change, so exposure was never the deciding question.

### The recurring problem

An exact pin is the one dependency shape that cannot drift forward on its own. Dependabot will not move `sharp: "0.35.0"`, and `dependency-review.yml` only inspects newly *added* dependencies at PR time. So an aging pin stays invisible until a weekly cron turns red days later, and a weekly cron that only goes red is a signal nobody is subscribed to.

`.osv-scanner.toml` already solved the mirror-image problem: every `[[IgnoredVulns]]` entry carries an `ignoreUntil`, which forces re-justification. Nothing applied that discipline to the `overrides` block.

### Proposed fix

PR incoming. Three parts:

1. Bump `sharp` to 0.35.4 and `adm-zip` to 0.6.1.
2. Add `.override-pins.json` (a reason and a `reviewBy` date per override) plus `test/override-freshness.test.ts` in the free suite, so a stale pin fails on the PR rather than in a cron.
3. Have the OSV Scanner workflow open an issue on a failed scheduled run, guarded on `repository.has_issues` so forks with issues disabled skip the job.

Start with the overrides in package.json, compare their review discipline with .osv-scanner.toml, and inspect the OSV Scanner workflow. Then read the proposed .override-pins.json and test/override-freshness.test.ts scope. Done means the published fixes are selected, override freshness is tested, and failed scheduled scans create issues only when repository.has_issues is enabled.

Written by the indexing model from the issue text.