fix(plugin-auth): scope the no-mail-transport rider on the invitation remedy

Clause-② review F1: the rider was FALSE on a reachable population. The
invitation carve-out is an ADMISSION verdict, not a verification bypass, so
the forced-verification mechanism this same line warns about for remedy (b)
applies to the INVITED login too. Measured by the reviewer on `open` and on
`email_domain` with a pending invitation: sign-up 200 with emailVerified
false, sign-in 403 EMAIL_NOT_VERIFIED — and the created row makes
probeSignInAccountsPresence answer 'present', so the report goes silent. An
operator following the PRIMARY remedy on a widened posture therefore got no
login and turned this report off: the loud-dead-end-to-quiet-dead-end
transition remedy (a) warns about, delivered by the remedy the card
commissioned.

The rider is now scoped to the default posture and carries the ordering the
reviewer measured to work — close a widened posture back to `invite_only`
BEFORE the invited person registers. All three copies (the string literal,
the block comment, the changeset) are aligned again.

Also folded in from the same review:

- N2: the invitation `email` must be stored LOWERCASE. `hasPendingInvitationFor`
  searches `where: { email: target.toLowerCase() }`, so a mixed-case row is
  never found and the sign-up is refused SELF_REGISTRATION_CLOSED — a silent
  dead end the line was sending operators into.
- N1: `(INVALID_EMAIL_OR_PASSWORD)` is row-shape-dependent — an issuer-less
  hand-written row answers 401, a fully-shaped one with a plaintext password
  answers 500. Widened to "a 401 or a 500 depending on the row shape, never a
  session", which holds for both.
- N3: dropped the "next boot" timing claim; under `single` the holder is
  usually promoted at the sign-up itself. The outcome is unchanged, so the
  line now states the outcome and not the timing.

Five new pins, because the clause that was wrong is the one nothing guarded:
the scoped phrasing itself; a widened posture admitting the invited creation
AND still forcing verification on it (the two mechanisms driven together,
since the false claim was that the first cancels the second); only the default
posture being mail-transport-free; the structural fact that an admission
verdict carries no field that could exempt verification; and N5 — every
widening posture in `AUDIENCE_POSTURES` is named in the message, read off the
vocabulary so a fourth one cannot leave the line silently stale.

⛔ Still message-text only: no admission semantics, no probe change, sign-up
path untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y

Author: os-warren

.changeset/boot-sign-in-report-remedy-text.md

@@ -9,6 +9,6 @@ That boot line fires on the deployment nobody can sign in to: human `sys_user` r
 - **"Open the audience posture so an existing person can register their own login"** produced no login. Every posture other than `invite_only` forces `requireEmailVerification` on, so a login registered that way is refused `EMAIL_NOT_VERIFIED` at its first sign-in — and a locked-out self-hosted install is usually the shape with no mail transport wired.
 - **"Write a `sys_account` credential row directly against the store"** was worse than useless. The `password` column carries a secret in the platform's own hash format, so a plaintext one authenticates nothing — and the probe behind this report asks only whether *any* `sys_account` row exists, so writing one turns the report off. The operator's first attempt at the named remedy turned the loud dead end back into the silent one the report was written to end.
 
-The line now names the path that was measured to work: write one pending `sys_invitation` row directly against the store — an address the directory does not already hold, `status` `pending`, a future `expires_at`, `inviter_id` of any existing `sys_user` — then register through the ordinary sign-up endpoint. The invitation carve-out admits that one creation under every posture, so no door is widened and no mail transport is needed; on the `single` tenancy posture the next boot promotes that account holder. The other two are still named, as the two things that look like remedies and are not, because an operator who is going to hand-write a credential row anyway needs to know it blinds the probe.
+The line now names the path that was measured to work: write one pending `sys_invitation` row directly against the store — a lowercase address the directory does not already hold, `status` `pending`, a future `expires_at`, `inviter_id` of any existing `sys_user` — then register through the ordinary sign-up endpoint. The invitation carve-out admits that one creation under every posture, so no door needs widening. It is an admission verdict and not a verification bypass, though, so the line scopes what follows from that: only under the default `invite_only` posture is the recovery mail-transport-free, and it tells the operator to close a widened posture back to `invite_only` before the invited person registers — otherwise the invited login is created, refused `EMAIL_NOT_VERIFIED` at first sign-in, and has silenced this report on the way past. On the `single` tenancy posture that account holder is then promoted to platform admin. The other two are still named, as the two things that look like remedies and are not, because an operator who is going to hand-write a credential row anyway needs to know it blinds the probe.
 
 **Message text only — no admission semantics move.** Nothing widens, nothing narrows, no accept set changes, and the probe is untouched: this changes what an operator *reads*, not what the platform *admits*. The long form of the same three facts is on the self-hosting deployment page.

packages/plugins/plugin-auth/src/boot-sign-in-reachability.test.ts

@@ -29,6 +29,7 @@ import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
 import {
   AUDIENCE_POSTURES,
   SystemObjectName,
+  audiencePermitsSelfRegistration,
   type AudiencePosture,
 } from '@objectstack/spec/system';
 import { AuthPlugin } from './auth-plugin';
@@ -146,6 +147,27 @@ describe('#14353 — the dead-end shape reports, by name, with consequence AND r
     expect(msg).toContain("'email_domain'");
   });
 
+  it('[#15588/F1] the no-mail-transport rider is SCOPED to the default posture', () => {
+    // ⛔ This rider was WRONG in the first version of this line, stated for
+    // EVERY posture. The carve-out is an ADMISSION verdict, not a verification
+    // bypass, so on `open`/`email_domain` the INVITED login is created and
+    // then refused EMAIL_NOT_VERIFIED — and creating it SILENCES this report
+    // on the way past. That is the loud-dead-end-to-quiet-dead-end transition
+    // remedy (b) warns about, delivered by the primary remedy. The exact
+    // scoped phrasing is asserted so no future edit can re-generalise it.
+    const msg = resolveNoSignInAccountReport(DEAD_END)!;
+    expect(msg).toContain('ADMISSION verdict, not a verification bypass');
+    expect(msg).toContain(
+      "under the default 'invite_only' posture no mail transport is needed either",
+    );
+    // the rider must name the invited login as the thing verification hits …
+    expect(msg).toContain('forces email verification on the INVITED login too');
+    // … and give the operator the ORDER, which is the actionable half
+    expect(msg).toContain("close the posture back to 'invite_only' BEFORE that person registers");
+    // [#15588/N2] the lookup lowercases, so a mixed-case row is never found
+    expect(msg).toContain('LOWERCASE address');
+  });
+
   it('[#15588] says NOTHING about what a SEEDED person\u2019s own re-registration answers', () => {
     // That response is #15587's surface and is being changed (a sign-up for an
     // address that already carries a `sys_user` row currently answers 200 and
@@ -209,22 +231,39 @@ describe('#14353 — the controls: every other shape is SILENT', () => {
 // pure decision function and the existing probe, and assert.
 // ---------------------------------------------------------------------------
 
-describe('#15588 — the named remedy WORKS: a pending invitation is admitted under EVERY posture', () => {
-  /**
-   * A self-serve sign-up by the invited address, judged by the real gate.
-   * The `email_domain` allowlist deliberately holds a DIFFERENT domain, so an
-   * admission under that posture can only have come from the invitation
-   * carve-out and never from the domain list.
-   */
-  const invitedSignUp = (posture: AudiencePosture, hasPendingInvitation: boolean) =>
-    decideAudienceAdmission({
-      audience: { posture, allowedEmailDomains: ['not-the-invitee.example'] },
-      creationClass: 'self-serve',
-      email: 'recovery@example.com',
-      hasPendingInvitation,
-      isBootstrap: false,
-    });
+/**
+ * A self-serve sign-up by the invited address, judged by the real gate.
+ * The `email_domain` allowlist deliberately holds a DIFFERENT domain, so an
+ * admission under that posture can only have come from the invitation
+ * carve-out and never from the domain list.
+ */
+const invitedSignUp = (posture: AudiencePosture, hasPendingInvitation: boolean) =>
+  decideAudienceAdmission({
+    audience: { posture, allowedEmailDomains: ['not-the-invitee.example'] },
+    creationClass: 'self-serve',
+    email: 'recovery@example.com',
+    hasPendingInvitation,
+    isBootstrap: false,
+  });
+
+/** A manager carrying one audience declaration, for the wiring mirror. */
+const AUDIENCE_TEST_SECRET = 'test-secret-at-least-32-chars-long!!';
+const managerWith = (audience?: Record<string, unknown>) =>
+  new AuthManager({
+    secret: AUDIENCE_TEST_SECRET,
+    baseUrl: 'http://localhost:3000',
+    dataEngine: engineOver({}).engine,
+    ...(audience ? { audience } : {}),
+  } as never);
+
+/** The declaration a widening posture needs to pass entry validation. */
+const wideningAudience = (posture: AudiencePosture) => ({
+  posture,
+  ...(posture === 'email_domain' ? { allowedEmailDomains: ['acme.example'] } : {}),
+  selfRegistrationPermissionSet: 'member_default',
+});
 
+describe('#15588 — the named remedy WORKS: a pending invitation is admitted under EVERY posture', () => {
   it('every posture in the vocabulary admits it — the message says "under EVERY audience posture"', () => {
     // Reading the vocabulary rather than listing it: a posture added later is
     // covered on the day it is added, and the message's "EVERY" stays honest.
@@ -290,28 +329,15 @@ describe('#15588 — the WARNING is true: ANY hand-written `sys_account` row sil
 });
 
 describe('#15588 — the WARNING is true: widening the posture FORCES email verification on', () => {
-  const SECRET = 'test-secret-at-least-32-chars-long!!';
-  const managerWith = (audience?: Record<string, unknown>) =>
-    new AuthManager({
-      secret: SECRET,
-      baseUrl: 'http://localhost:3000',
-      dataEngine: engineOver({}).engine,
-      ...(audience ? { audience } : {}),
-    } as never);
-
   it('`email_domain` and `open` both wire requireEmailVerification ON', () => {
     // The manager forces it from `audiencePermitsSelfRegistration(posture)` and
     // `getPublicConfig()` mirrors the wired flag, so this is the same fact the
     // message reports: a login registered under a widened posture cannot sign
     // in until a mail transport delivers the link.
     for (const posture of ['email_domain', 'open'] as const) {
-      const manager = managerWith({
-        posture,
-        ...(posture === 'email_domain' ? { allowedEmailDomains: ['acme.example'] } : {}),
-        selfRegistrationPermissionSet: 'member_default',
-      });
       expect(
-        manager.getPublicConfig().emailPassword.requireEmailVerification,
+        managerWith(wideningAudience(posture)).getPublicConfig().emailPassword
+          .requireEmailVerification,
         `posture ${posture}`,
       ).toBe(true);
     }
@@ -329,21 +355,70 @@ describe('#15588 — the WARNING is true: widening the posture FORCES email veri
     // wrong, and this is where that is caught.
     for (const posture of AUDIENCE_POSTURES) {
       expect(
-        (managerWith(
-          posture === 'invite_only'
-            ? undefined
-            : {
-                posture,
-                ...(posture === 'email_domain' ? { allowedEmailDomains: ['acme.example'] } : {}),
-                selfRegistrationPermissionSet: 'member_default',
-              },
-        ).getPublicConfig().emailPassword.requireEmailVerification),
+        managerWith(
+          posture === 'invite_only' ? undefined : wideningAudience(posture),
+        ).getPublicConfig().emailPassword.requireEmailVerification,
         `posture ${posture}`,
       ).toBe(posture !== 'invite_only');
     }
   });
 });
 
+describe('#15588/F1 — the carve-out ADMITS, it does not EXEMPT: the rider\u2019s scope, pinned', () => {
+  // The clause that was wrong is the one nothing guarded. These drive the two
+  // mechanisms together — the carve-out and the verification wiring — because
+  // the false claim was precisely that the first cancels the second.
+
+  it('a widened posture admits the INVITED creation AND still forces verification on it', () => {
+    for (const posture of AUDIENCE_POSTURES.filter(audiencePermitsSelfRegistration)) {
+      // admitted by the carve-out …
+      expect(invitedSignUp(posture, true), `posture ${posture}`).toMatchObject({ admit: true });
+      // … into a runtime that will refuse its first sign-in EMAIL_NOT_VERIFIED.
+      expect(
+        managerWith(wideningAudience(posture)).getPublicConfig().emailPassword
+          .requireEmailVerification,
+        `posture ${posture}`,
+      ).toBe(true);
+    }
+  });
+
+  it('ONLY the default posture is mail-transport-free — the half the message still promises', () => {
+    expect(invitedSignUp('invite_only', true)).toMatchObject({ admit: true });
+    expect(managerWith().getPublicConfig().emailPassword.requireEmailVerification).toBe(false);
+  });
+
+  it('an admission verdict CANNOT express a verification exemption', () => {
+    // Structural, and the reason the two mechanisms can never cancel: the
+    // carve-out's verdict carries no field that could turn verification off
+    // for the invited login. If one is ever added, the rider's scope changes
+    // and this is where that gets noticed.
+    expect(Object.keys(invitedSignUp('open', true)).sort()).toEqual([
+      'admit',
+      'grantPermissionSet',
+    ]);
+  });
+});
+
+describe('#15588/N5 — the message NAMES every posture that widens, read off the vocabulary', () => {
+  it('every self-registration-permitting posture appears in the message by name', () => {
+    // The message's quantifier ("every posture other than 'invite_only'") is
+    // pinned elsewhere against the WIRING. This pins the spellings the message
+    // hands the operator, read off the vocabulary rather than hardcoded, so a
+    // posture added to `AUDIENCE_POSTURES` cannot leave this line silently
+    // stale — it is named nowhere in the message and this goes red.
+    const msg = resolveNoSignInAccountReport(DEAD_END)!;
+    const widening = AUDIENCE_POSTURES.filter(audiencePermitsSelfRegistration);
+    expect(widening.length).toBeGreaterThan(0);
+    for (const posture of widening) {
+      expect(msg, `posture ${posture} must be named in the message`).toContain(`'${posture}'`);
+    }
+    // and the one that does NOT widen is named as the exception it is
+    expect(AUDIENCE_POSTURES.filter((p) => !audiencePermitsSelfRegistration(p))).toEqual([
+      'invite_only',
+    ]);
+  });
+});
+
 // ---------------------------------------------------------------------------
 // The probes
 // ---------------------------------------------------------------------------

packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts

@@ -42,9 +42,18 @@
  *    circuits on `hasPendingInvitation` BEFORE the posture switch, so a
  *    self-serve creation holding a pending, unexpired `sys_invitation`
  *    (`audience-posture.ts`, "The invitation carve-out") is admitted under
- *    every posture in `AUDIENCE_POSTURES`. No door is widened and no mail
- *    transport is involved. Pinned across the whole posture vocabulary, with
- *    the un-invited `invite_only` refusal as its control.
+ *    every posture in `AUDIENCE_POSTURES`. No door needs widening. ⚠️ But the
+ *    carve-out is an ADMISSION verdict and NOT a verification bypass, so the
+ *    third bullet below applies to the INVITED login too: only under the
+ *    default `invite_only` posture is the recovery mail-transport-free, and on
+ *    `open`/`email_domain` the invited login is created and then refused
+ *    `EMAIL_NOT_VERIFIED` — which also SILENCES this report, the very
+ *    transition the second bullet warns about, delivered by the primary
+ *    remedy. The message therefore scopes the no-mail-transport rider and
+ *    tells the operator to close the posture first; ⛔ never re-state that
+ *    rider for EVERY posture. Pinned across the whole posture vocabulary, with
+ *    the un-invited `invite_only` refusal as its control, and the scope itself
+ *    pinned beside it.
  *  - **A hand-written credential row blinds this very check.**
  *    {@link probeSignInAccountsPresence} asks only whether ANY
  *    `sys_account` row exists, so the operator's first attempt at "provision
@@ -259,16 +268,21 @@ export function resolveNoSignInAccountReport(facts: SignInReachabilityFacts): st
     'exists who could send an invitation. Boot continues and this deployment will keep LOOKING healthy — ' +
     'its only symptom is a 401 on credentials nobody holds. RECOVER IT FROM OUTSIDE THE RUNNING ' +
     'PRODUCT, and the path that works is ONE ROW: INVITE ONE ADDRESS — write a pending ' +
-    `'${SystemObjectName.INVITATION}' row directly against the store ('email' an address this ` +
-    `directory does NOT already hold, 'status' 'pending', a future 'expires_at', 'inviter_id' the id ` +
-    `of any existing '${SystemObjectName.USER}' row), then have that person register through the ` +
-    'ordinary sign-up endpoint. The invitation carve-out admits that ONE creation under EVERY ' +
-    'audience posture, so no door is widened and no mail transport is needed; on the ' +
-    "'single' tenancy posture the next boot then promotes that account holder to platform admin. " +
-    'Afterwards, re-run the provisioning job that seeded these people so it seeds their logins too. ' +
-    'TWO THINGS THAT LOOK LIKE REMEDIES AND ARE NOT: (a) HAND-WRITING A CREDENTIAL ROW — a ' +
-    `'${SystemObjectName.ACCOUNT}' row's 'password' column must carry a secret in the platform's own ` +
-    'hash format, so a plaintext password authenticates nothing (INVALID_EMAIL_OR_PASSWORD), and ' +
+    `'${SystemObjectName.INVITATION}' row directly against the store ('email' a LOWERCASE address ` +
+    `this directory does NOT already hold, 'status' 'pending', a future 'expires_at', 'inviter_id' ` +
+    `the id of any existing '${SystemObjectName.USER}' row — the pending-invitation lookup ` +
+    'lowercases the address it searches for, so a mixed-case row is never found), then have that ' +
+    'person register through the ordinary sign-up endpoint. The invitation carve-out admits that ' +
+    'ONE creation under EVERY audience posture, so no door needs widening — but it is an ADMISSION ' +
+    "verdict, not a verification bypass: under the default 'invite_only' posture no mail transport " +
+    "is needed either, whereas an 'open' or 'email_domain' posture forces email verification on the " +
+    "INVITED login too (see (b)), so close the posture back to 'invite_only' BEFORE that person " +
+    "registers. On the 'single' tenancy posture that account holder is then promoted to platform " +
+    'admin. Afterwards, re-run the provisioning job that seeded these people so it seeds their ' +
+    'logins too. TWO THINGS THAT LOOK LIKE REMEDIES AND ARE NOT: (a) HAND-WRITING A CREDENTIAL ' +
+    `ROW — a '${SystemObjectName.ACCOUNT}' row's 'password' column must carry a secret in the ` +
+    "platform's own hash format, so a plaintext password authenticates nothing — a 401 or a 500 " +
+    'depending on the row shape, never a session — and ' +
     `writing ANY '${SystemObjectName.ACCOUNT}' row SILENCES THIS REPORT, which asks only whether such ` +
     'a row EXISTS — the deployment stops being loudly broken and becomes quietly broken; and (b) ' +
     "OPENING THE AUDIENCE POSTURE — every posture other than 'invite_only' ('open', 'email_domain') " +