docs(permissions): the unscoped admin_full_access anchor confers platform-admin standing under single only

Since the walled legacy-anchor retirement (74832b6), resolveUserAuthzGrants
derives PLATFORM_ADMIN from an unscoped admin_full_access grant only when
postureEnforcesWall(resolveTenancyPosture()) is false, i.e. under `single`.
The authorization and permission-sets pages still said either anchor is
sufficient everywhere, and that the grant logs a once-per-process pointer.

Claude-Session: https://claude.ai/code/session_01VDtqoecgES7ScQYGbFVDRv
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/permissions/authorization.mdx

@@ -111,11 +111,16 @@ implementation detail:
    `viewAllRecords` / `modifyAllRecords` (super-user bypass, posture-gated)
    short-circuit the object's *business* RLS. Crossing the **tenant wall**,
    though, requires the **`PLATFORM_ADMIN` posture** (ADR-0099 D1). That posture
-   is derived at one site from **two anchors**, either of which is sufficient:
-   the deployment's **configured administrator list** — an address declared in
+   is derived at one site, and which anchors it reads depends on the
+   deployment's [tenancy posture](/docs/deployment/tenancy-modes). The
+   deployment's **configured administrator list** — an address declared in
    `OS_PLATFORM_OWNER_EMAIL`, matched against the caller's own stored and
-   **email-verified** `sys_user` row — and an **unscoped `admin_full_access`
-   grant** row. See
+   **email-verified** `sys_user` row — is sufficient under every posture. An
+   **unscoped `admin_full_access` grant** row is sufficient only under
+   `single`; under the walled postures (`group` / `isolated`) it is no longer
+   an anchor — the set it names still grants what any held set grants, but it
+   confers no `PLATFORM_ADMIN` standing, so there standing comes from
+   configuration alone. See
    [who holds `admin_full_access`](/docs/permissions/permission-sets#built-in-permission-sets)
    for both. A *scoped* grant, or
    piecemeal platform capabilities (`studio.access`, `manage_users`, …), grant

content/docs/permissions/permission-sets.mdx

@@ -165,8 +165,9 @@ Auto-seeded on boot by `plugin-security`
 | `viewer_readonly` | Per-org | Read access only | Auditors / read-only stakeholders |
 
 **Who holds `admin_full_access` is not (only) a grant row.** `PLATFORM_ADMIN`
-standing is derived at a single site from **two anchors**, and either one is
-sufficient:
+standing is derived at a single site from **two anchors**. Which of them is
+sufficient depends on the deployment's
+[tenancy posture](/docs/deployment/tenancy-modes):
 
 - **Configuration — `OS_PLATFORM_OWNER_EMAIL`.** The deployment declares its
   administrators as one email address, or a comma-separated list of them. A
@@ -177,10 +178,16 @@ sufficient:
   compared trimmed and lower-cased, so `Ada@Example.com` and `ada@example.com`
   are one administrator, not two half-matches. Nothing is stored and nothing is
   granted — the answer is recomputed from configuration on every resolution.
+  This anchor is read under every posture.
 - **An unscoped `admin_full_access` grant row** — a `sys_user_permission_set`
-  row with `organization_id = NULL`, the original anchor. It still confers
-  standing, and it is **deprecated**: a deployment resolving through it logs a
-  pointer, once per process, at the configuration line that re-anchors it.
+  row with `organization_id = NULL`, the original anchor. It confers standing
+  under the `single` posture only. Under the walled postures (`group` /
+  `isolated`) the row is no longer an anchor: the set it names still grants
+  what any held set grants, but it confers no `PLATFORM_ADMIN` standing, and
+  nothing is logged about it per request. If a walled deployment holding such a
+  row ends up with no usable configured administrator, the boot log says it has
+  zero platform administrators, names the account that holds the row, and points
+  at `OS_PLATFORM_OWNER_EMAIL` as the way to restore that account's standing.
 
 Which anchor a fresh deployment gets depends on its
 [tenancy posture](/docs/deployment/tenancy-modes). Under `single` the first