refactor(db): rename permission_history to site_activity_consent (BDMS-1381) - #1037

ADR5 uses "permission" for what staff are allowed to do, which is what
permission_grant records. permission_history records whether a landowner
lets the Bureau measure water levels, sample water chemistry, or install
a datalogger at their site. That is consent, so the table becomes
site_activity_consent, its columns become activity and allowed, and the
model becomes SiteActivityConsent.

The lexicon category for those activities changes from permission_type
to site_activity. activity_type was the obvious name, but
permission_grant already uses it as the category for data_type.

The migration is hand-written. Alembic autogenerate would drop the old
table and create a new one, deleting every consent on record (about
7,000 on staging). The migration reads constraint names from the catalog
because PostgreSQL 18 names NOT NULL constraints and 17 does not. A
guard stops the upgrade if anything on the table still has "permission"
in its name.

The view ogc_internal_water_well_field_operations needs no changes.
PostgreSQL tracks tables by OID and columns by position, so the view
follows the rename.

The well API still sends permissions, permission_type and
permission_allowed through serialization aliases, so OcotilloUI does not
change. Renaming those fields needs a staged release and is a separate
decision.

The SiteActivity enum is built from core/lexicon.json, so the API does
not depend on the data migration that renames the category row in
existing databases. That migration overwrites the category description
even if someone edited it, because the old text describes the old
concept.

Refs BDMS-1381