docs(adr-0056): reconcile Consequences with the P2/P4 pure model (#5970)

Two bullets in ADR-0056's Consequences still described the original
Option B (capabilities editable in Setup as an exception), contradicting
P2, P4, and Decision 3/4 of the same file:

- "Capabilities are authored once, in Setup, through the `sys_capability`
  picker" — P2 says capabilities are designed in the structured editor,
  "not authored in Setup", and the code agrees: the picker
  (CapabilityMultiSelectField) is rendered by Studio's
  PermissionMatrixEditor, while Setup stamps the read-only
  `permission-facet-link` widget on all six facets including
  `system_permissions`.
- "hence P2 keeps that grant in Setup and first-class", preceded by "an
  admin who ... lacks `studio.access` can no longer *design* them" —
  Decision 1/3 and A2 (revised) settle the opposite: the same editor has
  two entry points, and Setup's env-scope metadata route runs under
  `setup.access`, which is what dissolves the bootstrap knot.

Prose only; no code, no schema, no other file.


Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L

Co-authored-by: Claude <noreply@anthropic.com>

Author: yinlianghui

docs/adr/0056-permission-editing-studio.md

@@ -222,8 +222,9 @@ change framework source).
 
 - **One authoring path per concern.** Objects/fields/RLS/tabs/admin-scope are
   authored once, in Studio, through validated editors the explain engine (D6)
-  and publish linter (D7) can see. Capabilities are authored once, in Setup,
-  through the `sys_capability` picker.
+  and publish linter (D7) can see. Capabilities are designed once, in Studio,
+  through the `sys_capability` picker (P2); Setup only assigns permission sets
+  to users (P1b) and shows every facet read-only (P1).
 - **The Setup/Studio audience split (ADR-0084 / studio.app) is honored:**
   operators assign and grant-entry; makers design permissions.
 - **AI-authoring safety improves** exactly where ADR-0090 wants it: no security
@@ -240,10 +241,15 @@ change framework source).
     summary reads — so Studio edits aren't reflected in Setup until the projection
     refreshes. Display-freshness only (enforcement reads the authoritative
     metadata), but it needs a framework-side fix to close the loop.
-- **Studio becomes load-bearing for permission ops.** An admin who can assign
-  sets but lacks `studio.access` can no longer *design* them. That is the
-  intended boundary, but it makes "who holds `studio.access`" operationally
-  important — hence P2 keeps that grant in Setup and first-class.
+- **The structured editor becomes load-bearing for permission ops.** Designing a
+  set now means opening the permission matrix editor; no facet can be authored
+  from the record's own fields any more. The same editor has two entry points
+  (Decision 1) — the package-scoped Studio Access pillar (`studio.access`) and
+  Setup's own env-scope metadata route (`setup.access`) — so an operator who
+  lacks `studio.access` can still design a set at environment scope, including
+  granting `studio.access` itself. That is what dissolves the bootstrap knot A2
+  worried about, and why P2 puts the capability picker in the structured editor
+  instead of keeping a Setup exception (Decision 3).
 
 ## Open design questions