mig 130 primaryRoleId guard is advisory: app.allow_primaryroleid_write is caller-settable, and the wording calls it enforcement

Parent in spirit: PLUTO-669. Confirmed against APPLIED migration 130 by audit-general-ca (tag audit-general-ca-muwandbdb9dh), raised by coder-pluto-cc off audit's parallel finding on PLUTO-437 rev2. fn_guardPrimaryRoleId trusts current_setting('app.allow_primaryroleid_write'). That GUC is ordinary session state, not a capability, so any DB caller can SET LOCAL it to 'true' and then raw-UPDATE users.primaryRoleId. trg_users_guardPrimaryRoleId therefore blocks UNFLAGGED direct writes only - an accident, never an intent. Under the pooled owner role a custom GUC cannot provide more than that. Scope, deliberately narrow: 1. Revise the wording that reads as enforcement. Migration 130's own comments are immutable, so this is db/schema.md plus any row or doc text claiming the column cannot be written directly. The accurate claim is 'prevents unflagged writes'. 2. Decide whether policy-grade enforcement is wanted at all. If yes it needs a distinct privilege/actor boundary or a redesigned setter (audit-general-ca), NOT a louder GUC. Explicitly NOT in scope, both per audit: no rollback or hold of applied 130 - the ratchet points the right way and the status quo before it was worse. And do NOT copy PLUTO-437's unconditional-recomputation remedy here: that fits a column which is a pure function of other columns in the same row, whereas primaryRoleId has a legitimate external setter (fn_setPrimaryRole, the /admin/usuarios override) and is documented in auth-actions as a landing hint, not a scope decision. Not a PLUTO-437 apply dependency.