During the v0.14.0 prod deploy (2026-06-12) migration 042 was applied as
`sudo -u postgres`, leaving config.monitoring_areas + its SERIAL sequence owned
by postgres while the `central` app role expects ownership-based access. We
patched prod inline at the time with ALTER ... OWNER TO central, but the
migration FILE was never updated -- so a fresh install (dev clone, eventual prod
rebuild) would hit the same footgun.
Append two idempotent ALTERs (table + sequence OWNER TO central) so 042 is
self-healing. No-op when already central-owned. No new fields/event-types/
behavior, no migration re-apply, nothing to deploy (live prod table is already
central-owned via the earlier inline fix).
Test: test_grants_table_and_sequence_ownership_to_central asserts both ALTERs
are present (whitespace-insensitive, matching the existing static checks).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Generalize the single config.system bbox into a named config.monitoring_areas list with set-union semantics (kept if geometry intersects ANY area; no-geom always kept; empty list keeps everything). Migration 042 seeds 'default' from the existing bounds (49.0/41.8/-111/-117.5); old monitor_* columns preserved for v0.14.1. Archive + supervisor both apply the list. GUI /monitoring-area gains list/create/update/delete + multi-rectangle map.
