docs(permissions): move the membership-tier note to the better-auth boundary

The previous commit put an "app roles" section on the positions page, which
tripped `check:role-word` — the ADR-0090 D3 ratchet — by adding 11 uses of the
reserved word to the one page whose thesis is that positions are NOT roles.
The ratchet was right; raising its baseline there would have spent exactly what
D3 bought.

`positions.mdx` keeps only the factual correction to the tier list (the
parenthetical was already missing `delegated_admin`, and app-declared names now
belong in it), phrased to leave the file's word count unchanged at 6.

The substance moves to `authentication.mdx` under Organizations — the
better-auth boundary page, where `sys_member.role` is the sanctioned exception.
Baseline for that file ratcheted 2 → 5: two `sys_member.role` mentions and the
literal `"role"` JSON field in the invite sample.

Author: claude

content/docs/permissions/authentication.mdx

@@ -668,6 +668,40 @@ new AuthPlugin({
 })
 ```
 
+#### Positions as membership tiers
+
+`sys_member.role` is better-auth's own column and the one place ObjectStack
+keeps that vocabulary (ADR-0090 D3's single boundary exception). Beyond the
+four built-in tiers — `owner`, `admin`, `delegated_admin`, `member` — every
+[position](/docs/permissions/positions) and
+[permission set](/docs/permissions/permission-sets) your stack declares is
+registered as a valid value, so an invitation can name one directly:
+
+```http
+POST /api/v1/auth/organization/invite-member
+{ "email": "new.hire@example.com", "role": "sales_rep" }
+```
+
+On acceptance the value lands in `sys_member.role`, and the membership
+projection passes an unrecognized value through as a position name — so the
+invitee holds `sales_rep` in `current_user.positions` and resolves whatever
+permission sets are bound to it. Both `sys_invitation` and `sys_member` build
+their pickers from that same registered set, so the Setup UI offers your names
+alongside the built-ins.
+
+Two limits bound this as a provisioning path:
+
+- **It never hands out more authority than the issuer has.** An issuer below
+  `admin` grade may invite as plain `member` only, and no invitation may confer
+  a tier above the issuer's own. A delegated admin grants capability through
+  the invitation's *placement* (business unit + positions), authorized against
+  their `adminScope` — not through the membership tier, which nothing scopes.
+- **Only spec-compliant names are registered.** A declared name that is not
+  lowercase snake_case (`/^[a-z][a-z0-9_]*$/`, minimum 2 characters) is skipped
+  with a boot warning, and an invitation naming it is refused with
+  `ROLE_NOT_FOUND` — better-auth never learns a name the write path could not
+  store.
+
 ### Admin User Management
 
 With `plugins: { admin: true }` (forced on when SCIM is enabled), platform

content/docs/permissions/positions.mdx

@@ -16,11 +16,10 @@ of their own** — they only decide *who gets which sets*.
 > security identifiers and labels). The vocabulary is now unambiguous:
 > **permission set** = capability, **position** = distribution,
 > **business unit** = hierarchy. The single exception is better-auth's
-> internal `sys_member.role` (org-membership tier: `owner`, `admin`,
-> `delegated_admin`, `member`). A position name you declare here is also
-> registered as a valid `sys_member.role` value, so someone can be invited
-> directly into the position — see [Positions as membership
-> roles](#positions-as-membership-roles).
+> internal `sys_member.role` — the org-membership tier (`owner`, `admin`,
+> `delegated_admin`, `member`, **plus every position name your stack
+> declares**, so a person can be invited straight into a position; see
+> [Authentication](/docs/permissions/authentication#positions-as-membership-tiers)).
 
 ```typescript
 import type { Position } from '@objectstack/spec/identity';
@@ -90,36 +89,6 @@ is no singular `current_user.position` at runtime). Framework-seeded names:
 
 Test membership in RLS/CEL with `'org_admin' in current_user.positions`.
 
-## Positions as membership roles
-
-Every position and permission-set name your stack declares is registered as a
-valid organization role, so an invitation can name it directly:
-
-```http
-POST /api/v1/auth/organization/invite-member
-{ "email": "new.hire@example.com", "role": "sales_rep" }
-```
-
-On acceptance the value lands in `sys_member.role`, and the membership
-projection passes an unrecognized value straight through as a position name —
-so the invitee holds `sales_rep` in `current_user.positions` and resolves
-whatever permission sets are bound to it. Both `sys_invitation.role` and
-`sys_member.role` are pickers built from that same registered set, so the
-Setup UI offers your names alongside the built-ins.
-
-Two limits are worth knowing before you use this as a provisioning path:
-
-- **It is not a way to hand out more authority than you have.** An issuer
-  below `admin` grade may invite only as plain `member`, and no invitation may
-  ever confer a role above the issuer's own. A delegated admin grants
-  capability through the invitation's *placement* (business unit + positions),
-  which is authorized against their `adminScope` — not through the membership
-  role, which nothing scopes.
-- **Only spec-compliant names are registered.** A declared name that is not
-  lowercase snake_case (`/^[a-z][a-z0-9_]*$/`, min 2 characters) is skipped
-  with a boot warning, and an invitation naming it is refused with
-  `ROLE_NOT_FOUND`.
-
 ## Audience anchors: `everyone` and `guest` (ADR-0090 D5/D9)
 
 Two more built-in positions are **implicit** — they are never stored as

scripts/role-word-baseline.json

@@ -13,7 +13,7 @@
   "content/docs/kernel/contracts/data-engine.mdx": 1,
   "content/docs/kernel/events.mdx": 1,
   "content/docs/kernel/services-checklist.mdx": 4,
-  "content/docs/permissions/authentication.mdx": 2,
+  "content/docs/permissions/authentication.mdx": 5,
   "content/docs/permissions/authorization.mdx": 3,
   "content/docs/permissions/delegated-administration.mdx": 11,
   "content/docs/permissions/index.mdx": 1,