docs(permissions): align the Provenance clause and the admin guide with the packaged lock

Two more places still said a shipped permission set can be overlaid in the
environment. The Provenance paragraph's clause pointed "see below" at the
corrected bullet, which now says the opposite; administrator-guide Step 5 and
its FAQ answer told admins to overlay a shipped set.

Both now state the lock with the same population as the corrected bullet: a
set shipped in code (by an installed app, or a platform default) refuses an
environment edit with 403 NOT_OVERRIDABLE, and the remedy is clone and
adjust. Sets created here, clones and writable-runtime-package sets stay
editable in place. Step 5 keeps its order of preference, and the FAQ keeps
"or simply left unassigned".

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

Author: claude

content/docs/permissions/administrator-guide.mdx

@@ -159,10 +159,13 @@ is a structured spreadsheet — you never hand-write JSON:
 - **Capabilities** — named grants like `manage_users` or `studio.access`.
 
 Prefer the smallest change that works, in this order: **bind an existing set
-to a position** → **clone and adjust** → **author a new set**. Editing a set
-that shipped with an app creates an *environment overlay* — your change wins,
-survives upgrades, and can be reset back to the vendor baseline; the API name
-is immutable after creation. And keep the additive model in mind: author
+to a position** → **clone and adjust** → **author a new set**. A set shipped
+in code — by an app you installed, or as a platform default such as
+`member_default` — can't be edited in the environment (a save answers
+`403 NOT_OVERRIDABLE`): clone it and adjust the clone, which is your own set
+while upgrades keep reaching the original. Sets created here, clones, and sets
+saved into a writable runtime package are edited in place. The API name is
+immutable after creation. And keep the additive model in mind: author
 coherent capability bundles, never "subtraction sets".
 Full model: [Permission Sets](/docs/permissions/permission-sets).
 
@@ -193,7 +196,8 @@ org structure, it's a business unit.
 
 **Can I delete the built-in permission sets?** No — sets like
 `member_default` and `organization_admin` are the platform baseline. Shipped
-sets can be overlaid (Step 5) or simply left unassigned.
+sets can't be edited in place either, but they can be cloned and adjusted
+(Step 5) or simply left unassigned.
 
 ## Where is everything
 

content/docs/permissions/permission-sets.mdx

@@ -309,7 +309,7 @@ A package ships its own sets (`managedBy: 'package'` + `packageId`), seeded
 idempotently at boot and re-seeded on upgrade; environment-authored sets
 (`platform`/`user`) are never clobbered. The data layer refuses forging package
 provenance through the admin door (two-doors separation, evolved by ADR-0094 —
-ordinary edits of a packaged set become environment overlays, see below), which
+an edit of a set shipped in code is refused; clone it instead, see below), which
 is what makes package uninstall well-defined — and enforced: uninstalling a
 package (`DELETE /api/v1/packages/:id`) revokes its own sets, their
 position/user bindings, and its pending audience-binding suggestions in the