docs: correct module authorization comments

apps/api/tests/api-http.integration.ts

@@ -891,9 +891,11 @@ describe.sequential("live API — platform owner and delegated grant management"
   const ownerEmail = "[email protected]";
   const managerEmail = "[email protected]";
   const password = "correct horse battery staple";
-  // Module permission registration does not exist yet, so `core.authorization.grants.manage` —
-  // the one permission `CORE_PERMISSION_REGISTRY` actually declares — stands in for "some
-  // registered permission" throughout this scenario's explicit-grant lifecycle.
+  // This scenario intentionally proves out the explicit-grant lifecycle (create, list, use,
+  // revoke) against Core's own grant-management permission rather than a module's — a module
+  // permission would exercise the exact same route and evaluator code, adding coverage breadth
+  // without coverage depth. The "live API — installed module permission end-to-end" scenario
+  // below is where a real installed module's declared permission is proven end-to-end instead.
   const testPermission = "core.authorization.grants.manage";
   // Well-formed (passes `PermissionId` shape validation) but never registered — used to prove the
   // live route rejects it even for a caller who otherwise has full grant-management authority.

apps/api/tests/grants-routes.test.ts

@@ -25,8 +25,13 @@ const subjectUserId = parseEkklesiaUserId("subject_1");
 // (or, for listing, still return) an unregistered permission id rather than assuming registration.
 const permission = parsePermissionId("calendar.events.read");
 // A permission `CORE_PERMISSION_REGISTRY` actually declares, so tests that must reach
-// `store.createGrant`/`store.revokeGrant` can do so without also depending on module permission
-// registration, which does not exist yet.
+// `store.createGrant`/`store.revokeGrant` can do so. This suite exercises `createGrantsRoutes` in
+// isolation and intentionally injects `CORE_PERMISSION_REGISTRY` directly rather than a composed
+// platform registry — the routes have no notion of "Core" versus "module" permissions, they only
+// ever consult whichever registry they are given. Coverage proving a module-declared permission
+// works through the exact same route code lives in
+// `apps/api/tests/authorization-middleware.test.ts` (unit) and the "installed module permission
+// end-to-end" scenario in `apps/api/tests/api-http.integration.ts` (live).
 const registeredPermission = CORE_AUTHORIZATION_GRANTS_MANAGE;
 const grantId = parseGrantId("11111111-1111-1111-1111-111111111111");