the plugin system says permissions, not the other word

i named the field permissions and then narrated in the overloaded one anyway,
which is worse than either — the whole reason for the rename was that the word
already means three things here.

renamed what was mine: setPluginCapabilities -> setPluginPermissions,
pluginCapabilities -> pluginPermissions, and the prose throughout.

what remains is the platform's own vocabulary, not the plugin system's: the
 type it imports, and the  field on a dock manifest,
which is the shape the shell already renders. renaming those is a separate
change to a separate system and is the owner's to make.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/plugins/manifest.ts

@@ -15,9 +15,10 @@
 /**
  * A permission the plugin adds to the platform's permission system.
  *
- * Called `permissions` and NOT `capabilities`: that word already means three different things in this
- * codebase — the permission registry, the file-based item store under `$OFFICER_ROOT/capabilities`, and
- * the routing keys a sidecar registers with. A fourth would be one too many.
+ * Called `permissions`, and that word is used throughout the plugin system deliberately. The other one
+ * already means three different things here — the permission registry, the file-based item store under
+ * `$OFFICER_ROOT/capabilities`, and the routing keys a sidecar registers with — and a fourth meaning
+ * would be one too many. Nothing in this system uses it.
  */
 export type PluginPermission = {
   /** Stable identifier, stored as the grant's subject. Renaming one is a data change. */
@@ -26,10 +27,10 @@ export type PluginPermission = {
   description: string;
   // There is deliberately NO `ownerOnly`, and no kind of any sort.
   //
-  // Every plugin permission is grantable, per role, at read or write — the same configuration as every
-  // core capability, on the same page, with no special cases to learn. A plugin that wanted to be
-  // owner-only would be a plugin the owner cannot delegate, and "which members may reach this" is a
-  // decision that belongs to the person running the server rather than to the person who wrote the code.
+  // Every plugin permission is grantable, per role, at read or write — the same configuration the
+  // platform's own permissions get, on the same page, with no special cases to learn. A plugin that
+  // wanted to be owner-only would be a plugin the owner cannot delegate, and "which members may reach
+  // this" is a decision belonging to whoever runs the server rather than whoever wrote the code.
   //
   // Finer visibility — whose rows a member sees, what a read means for this plugin's data — is the
   // PLUGIN's business and lives in its own queries. The platform's answer is uniform: read, write, or
@@ -151,9 +152,9 @@ export function manifestProblems(appName: string, manifest: Partial<PluginManife
         problems.push(`permissions[${i}].key is required`);
         continue;
       }
-      // The permission key shares the capability registry's namespace, so a plugin colliding with a core
-      // capability would silently widen or narrow it. Prefixing is not enforced here — the installer
-      // checks against the live registry, which is the only thing that knows what is taken.
+      // The key shares the platform's permission namespace, so a plugin colliding with a built-in one
+      // would silently widen or narrow it. Prefixing is not enforced here — the installer checks against
+      // the live registry, which is the only thing that knows what is taken.
       if (typeof permission.label !== 'string' || !permission.label) {
         problems.push(`permissions[${i}].label is required`);
       }