Apply a boundary change on every replica, not just the one that received it

CHANGELOG.md

@@ -86,6 +86,15 @@ Sessions survive and nobody signs in again.
   is unavailable never blocks a sign-in.
 
 ### Fixed
+- **A boundary rule only applied on the server that received it.** The action policy was read from
+  the database once at boot and then kept in the process that held it, so a deny rule an
+  administrator added was enforced by whichever of the server processes answered them, and every
+  other one went on deciding with the list it read at boot. Behind a load balancer that meant the
+  rule applied to roughly one action in however many processes are running, while the screen and the
+  audit row both reported it saved. A change is now announced through Postgres and every process
+  re-reads the row, including after its connection drops, so a rule added or reset a moment ago
+  applies to the next action wherever it lands. Nothing to configure; a single-process deployment
+  behaves as before.
 - **A deployment with no identity provider came up open by default.** Covered under Changed above,
   and listed here too because it is the one on this list that was reachable from the internet.
 - **Registering a company's identity provider was owned by whoever registered it.** Better Auth

server/drizzle/0006_snapshot_catches_up_with_the_schema.sql

@@ -0,0 +1,20 @@
+-- No-op DDL. This migration exists to bring `meta/0005_snapshot.json` back into agreement with
+-- `core.ts`, not to change any database.
+--
+-- Two fields moved in #87 and the snapshot was not regenerated, so `drizzle-kit generate` kept
+-- emitting these statements and the `migrations` drift probe kept failing on the dirty tree. The
+-- snapshot describes a state no deployment is in:
+--
+--   * `accounts.issuer` is absent from `0000_schema.sql`, added nullable by `0002_sign_in.sql`, and
+--     filled by `0003_backfill_account_issuer.sql`. `SET NOT NULL` was never applied, so dropping it
+--     here drops a constraint that does not exist.
+--   * `0004_identity_provider_outlives_its_registrar.sql` already dropped and re-added the
+--     `sso_providers` foreign key with `ON DELETE set null`. Re-landing it here lands it on the
+--     constraint it already has.
+--
+-- Nothing to look for behind these three lines: no schema change was intended and none happens.
+
+ALTER TABLE "sso_providers" DROP CONSTRAINT "sso_providers_user_id_users_id_fk";
+--> statement-breakpoint
+ALTER TABLE "accounts" ALTER COLUMN "issuer" DROP NOT NULL;--> statement-breakpoint
+ALTER TABLE "sso_providers" ADD CONSTRAINT "sso_providers_user_id_users_id_fk" FOREIGN KEY ("user_id") REFERENCES "public"."users"("id") ON DELETE set null ON UPDATE no action;