deploy: apps/web has no schema-drift guard and will boot against a schema the worker refuses

Follow-up from #180, which added a drift guard to apps/worker/start.sh only.

apps/web/start.sh runs a bare prisma migrate deploy against the same database with no drift check. After #180, a drifted database blocks the worker while web deploys happily and serves traffic against a schema it does not match.

Two specific consequences:

1. The failure class #180 fixes — a migration recorded as applied but never effective — is not worker-specific. Web reads the same database.
2. #180's repair migration asserts its own postcondition and fails loudly on a mis-shaped SystemConfig. But if web deploys first, it applies that migration with no guard around it, so the repair window can close before the worker ever looks.

Either extract the guard into a script both services source, or state in apps/worker/start.sh why web is deliberately exempt. Note the guard is intentionally crude (any difference is fatal, with OUTPOST_ALLOW_SCHEMA_DRIFT as the release valve) — see the comment block in apps/worker/start.sh for why a cleverer classifier was removed.

Start by reading the guard comment block in apps/worker/start.sh, then compare its entry point with apps/web/start.sh and the bare prisma migrate deploy. Determine whether the guard should be shared or web should be explicitly exempt; done means both services have consistent, documented drift behavior and the OUTPOST_ALLOW_SCHEMA_DRIFT release valve remains clear.