fix(runtime): ask the three domain floors about the user id alone — they serve a user and have no system-context arm

Passing isSystem added three elevation read sites the system-context page
does not carry, for no behaviour: each domain already refused a system
context with no user.

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

Author: claude

packages/runtime/src/domains/keys.ts

@@ -75,11 +75,12 @@ export async function handleKeysRequest(
     // below the method check, so an anonymous caller using any verb but POST
     // was answered the 405 describing the route's shape instead of the 401
     // every domain off the closed list of doors answers. A key is minted FOR a
-    // user, so past this statement a caller always has a user id: the
-    // `!ec.userId` arm refuses an internal system context that carries none,
-    // with the same answer it always had.
+    // user, so the decision is asked about the user id alone: this domain has
+    // no system-context arm (an internal system context was refused here before
+    // as it is now), and the `!ec` / `!ec.userId` arms only narrow the type for
+    // the compiler.
     const ec = context.executionContext;
-    if (!ec || shouldDenyAnonymous({ userId: ec.userId, isSystem: ec.isSystem }) || !ec.userId) {
+    if (shouldDenyAnonymous({ userId: ec?.userId }) || !ec || !ec.userId) {
         return {
             handled: true,
             response: deps.error(ANONYMOUS_DENY_MESSAGE, ANONYMOUS_DENY_STATUS, { code: ANONYMOUS_DENY_CODE }),

packages/runtime/src/domains/notifications.ts

@@ -123,11 +123,12 @@ export async function handleNotificationRequest(
     // an anonymous caller learns nothing about the deployment, and a face added
     // below inherits the refusal instead of having to remember its own.
     //
-    // The inbox is per user, so past this one statement a caller always has a
-    // user id: the `!userId` arm refuses an internal system context that carries
-    // none (it has no inbox to read), with the same answer it always had.
+    // The inbox is per user, so the decision is asked about the user id alone:
+    // this domain has no system-context arm (an internal system context carries
+    // no inbox to read, and was refused here before as it is now), and the
+    // `!userId` arm only narrows the type for the compiler.
     const userId: string | undefined = context.executionContext?.userId;
-    if (shouldDenyAnonymous({ userId, isSystem: context.executionContext?.isSystem }) || !userId) {
+    if (shouldDenyAnonymous({ userId }) || !userId) {
         return {
             handled: true,
             response: deps.error(ANONYMOUS_DENY_MESSAGE, ANONYMOUS_DENY_STATUS, { code: ANONYMOUS_DENY_CODE }),

packages/runtime/src/domains/share-links.ts

@@ -127,13 +127,12 @@ export async function handleShareLinksRequest(
     // token admits. It used to sit inside the body, below the service probe, as
     // the management faces' own `!userId` check, so a deployment without the
     // share-link service answered an anonymous caller the 501 capability
-    // disclosure instead of the 401. A link is managed BY a user, so past this
-    // statement a non-public face always has a user id: the `!userId` arm
-    // refuses an internal system context that carries none, with the answer it
-    // always had.
+    // disclosure instead of the 401. A link is managed BY a user, so the
+    // decision is asked about the user id alone: these faces have no
+    // system-context arm (an internal system context was refused here before
+    // as it is now).
     if (!isPublic) {
-        const ec = context.executionContext;
-        if (shouldDenyAnonymous({ userId: ec?.userId, isSystem: ec?.isSystem }) || !ec?.userId) {
+        if (shouldDenyAnonymous({ userId: context.executionContext?.userId })) {
             return {
                 handled: true,
                 response: deps.error(ANONYMOUS_DENY_MESSAGE, ANONYMOUS_DENY_STATUS, { code: ANONYMOUS_DENY_CODE }),