fix(sharing,approvals,runtime,security): platform authority is the posture RUNG, never a name in positions[]

Four server-side readers derived platform-operator authority from a NAME in
`ExecutionContext.positions` rather than from the ADR-0095 capability rung.

`positions[]` is the security axis, so it carries ADR-0057 D4
`sys_user_position` names alongside the built-ins. That table is `apiEnabled`
with unconstrained `position` values, so a tenant could mint a row spelling
`platform_admin` for one of their own users: `resolveUserAuthzGrants` pushes the
name straight onto `grants.positions`, while `grants.posture` is derived from
the unscoped `admin_full_access` grant and nothing else and correctly stays
`MEMBER`. Every reader of the name therefore answered true for a principal
enforcement treats as an ordinary member.

`resolve-authz-context.ts` states the rule at `hasPlatformAdminStanding` --
"read the RUNG, never positions.includes(...)" -- but a comment is not a gate,
and it stopped none of these four. Each now tests
`posture === 'PLATFORM_ADMIN'`, byte-for-byte what that predicate returns.

Each site was DRIVEN rather than read, with the D4 row present, before and
after. Three were live; the fourth is reported as what it measured, not as what
the shape suggested:

- plugin-sharing `hasPlatformAuthority` -- the minted row satisfied
  `assertResolvableAdminScope`, so an org-less caller holding only the
  ORG-scoped `manage_sharing` capability was answered with every tenant's
  sharing rules, and could delete platform-global rows.
- plugin-approvals `isOverrideActor` -- already read the rung and then ORed the
  name onto it, which is no protection. Because that arm crosses the tenant
  wall, the minted row moved another organization's pending request to
  `approved`.
- runtime ADR-0126 §5 activation gate -- under a walled posture this is the
  only thing between a tenant org admin and the install-wide activation row, so
  the minted row reopened #10243 with a durable row behind it.
- plugin-security `derivePosture` -- NARROWER, and measured: the name-read sits
  behind an early `ctx.posture` return that `buildContextForUser` always
  populates, so the shipping path was already gated and the D4 row never moved
  it. What the read did reach was a posture-less hand-built context, where it
  made the panel REPORT `PLATFORM_ADMIN` for a MEMBER.

Each site gets a mutated three-way-agreement pin whose population is stated in
its own header, and each contains the case whose absence let #15948 round 1
pass its author's own check: a D4 row that spells the built-in name, with the
name-read, the site's own gate and the rung asserted together.

Six existing fixtures pinned the removed branches and are migrated, not
deleted: four spelled a platform operator as the bare NAME (they now carry the
rung a resolved operator always has, plus a new name-only refusal arm), and two
in `explain-engine.test.ts` asserted the removed derivation directly and are
inverted with the reason recorded in place.

Refs #15981

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y

Author: claude

.changeset/positions-name-is-not-platform-authority.md

@@ -0,0 +1,21 @@
+---
+"@objectstack/plugin-sharing": patch
+"@objectstack/plugin-approvals": patch
+"@objectstack/plugin-security": patch
+"@objectstack/runtime": patch
+---
+
+Four server-side authorization sites stop deriving platform-operator authority from a NAME in `ExecutionContext.positions`, and read the ADR-0095 posture rung instead.
+
+`positions[]` is the security axis, so it carries ADR-0057 D4 `sys_user_position` names alongside the built-ins. `sys_user_position` is `apiEnabled` and its `position` values are unconstrained, so a tenant could mint a row spelling `platform_admin` for one of their own users: `resolveUserAuthzGrants` pushed that name straight onto `grants.positions`, while `grants.posture` — derived from the unscoped `admin_full_access` grant and nothing else — correctly stayed `MEMBER`. Every reader of the name therefore answered `true` for a principal enforcement treats as an ordinary member. `resolve-authz-context.ts` states the rule at `hasPlatformAdminStanding` ("read the RUNG — never `positions.includes(...)`"), but a comment is not a gate and these four had not followed it.
+
+Each site now tests `posture === 'PLATFORM_ADMIN'`, byte-for-byte what `hasPlatformAdminStanding` returns:
+
+- **`plugin-sharing`** — `hasPlatformAuthority`. The minted row satisfied `assertResolvableAdminScope`, so an org-less caller holding only the ORG-scoped `manage_sharing` capability was answered with **every tenant's** sharing rules, and could delete platform-global rules. The `manage_platform_settings` capability spelling is unchanged.
+- **`plugin-approvals`** — `isOverrideActor`. This predicate already read the rung and then ORed the name onto it, which is no protection: an OR is only as strong as its weakest arm. Because the platform arm deliberately crosses the tenant wall, the minted row let a member of one organization approve, reject or recall a **different organization's** pending request while holding no slot in its slate. The `ADMIN_FULL_ACCESS` capability arm and both TENANT_ADMIN arms are unchanged.
+- **`runtime`** — the ADR-0126 §5 activation gate. Under a `group` or `isolated` posture this gate is the only thing between a tenant org admin and the **install-wide** `sys_metadata_activation` row, so the minted row reopened #10243 with a durable row behind it.
+- **`plugin-security`** — `derivePosture` in the explain engine. Narrower than the other three, and stated precisely rather than overclaimed: the name-read sat behind an early `ctx.posture` return that `buildContextForUser` always populates, so the shipping path was already gated and a D4 row never moved it. What the read did reach was a posture-less hand-built context, where it made the panel **report** `PLATFORM_ADMIN` for a principal enforcement treats as a MEMBER — a misreport rather than an admission, but in the one tool an administrator opens to check exactly this.
+
+No behaviour changes for a genuine platform operator: their resolved context carries the rung, and the built-in position is still projected onto `positions[]` for display and predicate use. What changes is that the name alone no longer answers the authorization question.
+
+Graded `patch` on the surface it moves: no exported type, signature or contract changes, and no authorable metadata is added, removed or renamed. The only observable difference is that a principal who never held the capability grant stops being admitted — which is the defect, not a feature anyone could have depended on.

content/docs/permissions/system-context.mdx

@@ -137,15 +137,15 @@ The largest single consumer — **17 of the 105 sites**.
 | 36 | `sys_record_share` reads are **not** self-scoped | Get: tenant-wide share listing without `manage_sharing` | `sharing-plugin.ts:1189` |
 | 37 | Share-link policy `enabled` check bypassed; system callers re-enter under a system context | Get: link **creation** while the policy is off — resolution is **not** bypassed since #14033 (`publicSharing.enabled` is a standing policy held at every redemption): a link minted this way does not resolve until the block is enabled | `plugin-sharing/src/share-link-service.ts:459`, `:513`, `:517`, `:590`, `:620` |
 | 38 | Sharing-rule provenance stamp skipped | Lose: the row is not marked as an admin customization — seeder / `defineRule` / boot reconcilers are "the package door" | `sharing-rule-provenance.ts:47` |
-| 39 | Sharing-rule service write + delete paths return early | Lose: the manage-rules gate on the service surface, and the platform-global-rule delete guard | `sharing-rule-service.ts:278`, `:503` |
+| 39 | Sharing-rule service write + delete paths return early | Lose: the manage-rules gate on the service surface, and the platform-global-rule delete guard | `sharing-rule-service.ts:279`, `:518` |
 
 ### 4. Approvals, reports, attachments, comments, knowledge
 
 | # | Behaviour when `isSystem` | Package | What you get / what you lose | Anchor |
 |:--|:---|:---|:---|:---|
 | 40 | **Approval record lock released** — a locked record is writable | plugin-approvals | Get: engine self-writes (the status mirror) pass. Lose: the lock that stops edits while an approval is live. Note there is deliberately **no admin exemption** here — only `isSystem` | `lifecycle-hooks.ts:347` |
 | 41 | Delegation write guard bypassed | plugin-approvals | Get: service / seed / import may write delegation rows naming another delegator | `lifecycle-hooks.ts:570` |
-| 42 | Approval actor / submitter / pending-approver checks bypassed (8 sites) | plugin-approvals | Get: approve, reject, recall, reassign without being a pending approver or the submitter | `plugin-approvals/src/approval-service.ts:1093`, `:1202`, `:3458`, `:3606`, `:3774`, `:3845`, `:4034`, `:4074` |
+| 42 | Approval actor / submitter / pending-approver checks bypassed (8 sites) | plugin-approvals | Get: approve, reject, recall, reassign without being a pending approver or the submitter | `plugin-approvals/src/approval-service.ts:1096`, `:1219`, `:3475`, `:3623`, `:3791`, `:3862`, `:4051`, `:4091` |
 | 43 | Saved-report ownership is **assignable**, and an update may reassign it | plugin-reports | Get: `ownerId` from input is honoured. A non-system caller always owns what it creates and can never reassign | `plugin-reports/src/report-service.ts:404`, `:425` |
 | 44 | Saved-report access / export / mutation gates bypassed | plugin-reports | Get: read, bulk-export and overwrite any report | `plugin-reports/src/report-service.ts:343`, `:372`, `:447`, `:684` |
 | 45 | Attachment access hooks return early (insert + update + delete, and the read AST) | service-storage | Lose: attachment visibility scoping | `attachment-access-hooks.ts:300`, `:349`, `:448`, `:524` |
@@ -164,7 +164,7 @@ The largest single consumer — **17 of the 105 sites**.
 | 53 | MCP principal check satisfied | runtime | Get: MCP surface reachable with no user | `domains/mcp.ts:61` |
 | 54 | Package REST route capability gate bypassed | rest | Get: package read/write over REST without `manage_metadata` / `studio.access` / `setup.access` | `package-routes.ts:102` |
 | 55 | Package domain capability gates bypassed | runtime | Get: package management and package-inventory reads without the capability | `domains/packages.ts:241`, `:274` |
-| 56 | Activation write / authoring refusals do not fire | runtime | Get: activation artifacts writable and authorable without the activation-authoring capability | `activation-gate.ts:138`, `:189` |
+| 56 | Activation write / authoring refusals do not fire | runtime | Get: activation artifacts writable and authorable without the activation-authoring capability | `activation-gate.ts:157`, `:211` |
 | 57 | Automation run-state read, flow-authoring write and unrelated-screen read all pass | runtime | Get: run state, flow writes and screen reads with no grant | `domains/automation.ts:254`, `:545`, `:635` |
 | 58 | Audience-binding suggestion recording skipped | plugin-security | Lose: install-time suggestions are not recorded for system callers | `suggested-audience-bindings.ts:703` |
 | 59 | Email-template / webhook provenance stamps skipped | plugin-email, plugin-webhooks | Lose: the row is not marked as an admin customization | `email-template-provenance.ts:59`, `webhook-provenance.ts:50` |