1456 Update registration tables with comments

[Sepehr-Sobhani]

ISSUE 1456

⚠️ This PR added approximately 7,000 new lines of code through the new migration file. We should consider squashing migrations again two or three releases after the latest ticket about adding metadata to the tables is completed.

What is SeparateDatabaseAndState?

Django's migration system maintains two parallel layers:

• Database state — what actually exists in PostgreSQL
• Migration state — Django's internal record of the schema, built by replaying all migration operations in order

Normally these stay in sync because operations like AlterField do both at once: run the SQL against the database and update Django's tracked state. SeparateDatabaseAndState is an escape hatch that lets you decouple these two layers, providing separate operation lists for each:

migrations.SeparateDatabaseAndState(
    database_operations=[...],  # what actually runs against PostgreSQL
    state_operations=[...],     # what Django uses to update its internal state only
)

The issue

Django's AlterField on a FK or OneToOneField generates ALTER TABLE ... ALTER COLUMN ... TYPE ... in PostgreSQL. PostgreSQL blocks this statement when the column is referenced in a trigger WHEN clause or an RLS policy expression, producing:

cannot alter type of a column used in a trigger definition
cannot alter type of a column used in a policy definition

Since the only actual schema change needed is adding a db_comment, we use COMMENT ON COLUMN instead — a separate DDL statement that does not touch the column type and is not blocked by triggers or policies. However, using a plain RunSQL("COMMENT ON COLUMN ...") would leave Django's migration state out of sync, causing makemigrations to re-detect the missing db_comment and regenerate the same failing AlterField on the next run.

SeparateDatabaseAndState solves both problems:

• database_operations runs COMMENT ON COLUMN — safe, avoids the conflict
• state_operations runs AlterField against Django's state only (never touches the DB) — keeps the tracked schema in sync

The affected columns, grouped by the reason they are blocked:

Blocked by pgtrigger trigger WHEN clauses:

Trigger	Table	Column
restrict_bcghg_id_unless_operation_registered	erc.facility	bcghg_id_id
restrict_bcghg_id_unless_registered	erc.operation	bcghg_id_id
restrict_boro_id_unless_registered	erc.operation	bc_obps_regulated_operation_id

Blocked by RLS policy subquery expressions:

Policy	Table	Column
compliance_obligation_industry_user_delete_policy and operation policies	erc.operation	operator_id
Multiple compliance and registration policies	erc.user_operator	operator_id
Multiple compliance and registration policies	erc.user_operator	user_id

[dleard]

Looks good! I see a couple places where a URL to the source regulation may be helpful?