fix: enforce registered authorization permissions

Two related fail-closed gaps let a well-formed but never-declared
permission id slip through:

- POST /api/v1/grants created explicit grants for any well-formed
  PermissionId without checking the injected permission registry,
  allowing dormant grants for invented identifiers that could become
  effective the moment those identifiers were registered later.
- createAuthorizationEvaluator validated the permission id only inside
  the restricted-baseline branch, so a malformed permission combined
  with the public or authenticated baseline could still return allowed.

Both now fail closed: the grants route checks the target permission
against the trusted registry before calling store.createGrant (sanitized
403, no store or audit write), and the evaluator validates permission
shape before any baseline is allowed to return an allowed decision,
without adding a registry dependency to the evaluator itself.

The live integration lifecycle test switched from an unregistered
calendar.events.read to the registered core.authorization.grants.manage
permission, since module permission registration does not exist yet.

core/src/authorization/evaluator.ts

@@ -32,8 +32,13 @@ export class AuthorizationEvaluationError extends Error {
 
 export interface AuthorizeRequest {
   readonly principal: EkklesiaPrincipal;
-  /** Validated internally via the branded `PermissionId` schema; a malformed or unrecognizable
-   * value denies rather than throwing — "unknown or malformed permissions fail closed." */
+  /** Validated internally via the branded `PermissionId` schema *before any baseline can return an
+   * allowed decision* — a malformed or unrecognizable value denies rather than throwing, for
+   * `public` and `authenticated` baselines exactly as much as `restricted`. This is shape
+   * validation only: the evaluator has no registry and cannot tell a well-formed-but-unregistered
+   * permission from one that is actually registered. Only a trusted caller consulting a
+   * `PermissionRegistry` (`core/src/authorization/permissions.ts`) before calling `authorize` can
+   * make that distinction — see that module and `apps/api/src/authorization-middleware.ts`. */
   readonly permission: unknown;
   /** Validated internally against the known `public`/`authenticated`/`restricted` set; anything
    * else denies rather than throwing, for the same fail-closed reason. */
@@ -80,6 +85,16 @@ export function createAuthorizationEvaluator(
         return AUTHORIZATION_DENIED;
       }
 
+      // Shape-validated before any baseline is allowed to return `allowed` — a malformed
+      // permission id must deny under `public` and `authenticated` exactly as much as under
+      // `restricted`, even though neither of the first two ever reads `parsedPermission.data`.
+      // This is a pure, synchronous check: it never touches the grant or platform-owner ports, so
+      // `public`/`authenticated` still resolve with no database lookup at all.
+      const parsedPermission = safeParsePermissionId(request.permission);
+      if (!parsedPermission.success) {
+        return AUTHORIZATION_DENIED;
+      }
+
       if (parsedBaseline.data === "public") {
         return AUTHORIZATION_ALLOWED;
       }
@@ -96,11 +111,6 @@ export function createAuthorizationEvaluator(
         return AUTHORIZATION_DENIED;
       }
 
-      const parsedPermission = safeParsePermissionId(request.permission);
-      if (!parsedPermission.success) {
-        return AUTHORIZATION_DENIED;
-      }
-
       let scope: AuthorizationScope | undefined;
       if (request.scope !== undefined) {
         const parsedScope = safeParseAuthorizationScope(request.scope);