Fix notification ID sequence exhaustion

[raymondjacobson]

Summary

• widen notification.id and notification_id_seq from 32-bit integer to bigint
• widen Go and PL/pgSQL consumers that store notification IDs
• make the migration idempotent and fail within 5 seconds when the required table lock is unavailable

Production rollout warning

Production's notification table is approximately 13 GB (6.1 GB heap and 6.4 GB indexes, about 26 million rows). PostgreSQL must rewrite it while holding an ACCESS EXCLUSIVE lock.

Coordinate a maintenance window and quiesce notification readers/writers before applying this migration. The migration uses a 5-second lock_timeout so an unattended deploy fails instead of leaving requests queued. After the lock is acquired, statement_timeout is disabled so the rewrite can finish.

Validation

• applied the migration to a fresh local database
• reapplied it to verify idempotency
• set the sequence to 2147483647 and successfully inserted notification ID 2147483648 as bigint
• verified all three trigger functions use bigint locals
• go test -run '^$' ./api/... ./jobs/...