No test coverage for any cron route — 14+ untested data-pipeline endpoints

[NewCoder3294]

Where

`apps/web/app/api/cron/**`

Problem

Zero `.test.ts` files exist anywhere under `app/api/cron/` despite ~14 cron handlers driving critical data flow: incident archival, VLM enrichment queue, SMS notifications, camera validation, alert dispatch, etc.

```bash
$ find apps/web/app/api/cron -name ".test.ts" | wc -l
0
$ ls apps/web/app/api/cron//route.ts | wc -l
14
```

These handlers all share the same shape (auth → query Supabase → side-effect → JSON response) so they're actually well-suited to a shared test harness.

Suggested approach

1. Set up one shared cron-route test helper in `apps/web/tests/helpers/cron.ts` that builds an authorized `NextRequest`, mocks `adminClient()`, and asserts the JSON shape.
2. Cover one cron per PR — keeps the diff reviewable. Order of priority:
   • `send-alerts` (user-visible — duplicate emails, missed alerts) — see send-alerts cron: TOCTOU race can send duplicate emails on overlapping runs #16
   • `process-vlm-queue` (spends API budget) — see process-vlm-queue cron uses bespoke auth instead of shared isAuthorizedCron() #17
   • `archive-incidents` (data loss risk on bad RPC response)
   • `validate-cameras`
   • The rest

Good first issue?

The first one (set up the helper + cover one route end-to-end) is a great first contribution — well-scoped, no need to understand the whole product, and high signal.

Severity

High — every uncovered cron is a class of silent-failure bug we can't catch in CI.