fix(plugin-auth): say remedy (b) cannot recover an EXISTING person at all

Input from #15587's dev, who searched before concluding it: that fix does not
make this remedy true, it makes it fail HONESTLY — the person still cannot
register a login, and for an EXISTING person that is by design, not by defect
(#14349 is closed on option A, the door stays shut, which the line above
already cites).

The previous wording rested entirely on forced email verification. That is the
story for a NEW address. The operator reading this line is usually trying to
recover somebody the directory already holds, and for them the posture is not
the lever at all: self-registration is a user-CREATION path, so it cannot hand
a login to an address that already carries a `sys_user` row, whatever the
posture. Both failures are real; they are different failures, and the more
likely one was missing.

⛔ Stated in MECHANISM terms, deliberately. #15587 is a draft under review, so
this line asserts no wire status for that refusal — the M2 pin that forbids
USER_ALREADY_EXISTS / "answers 200" / "persists nothing" / "no new row" in
this message stays green, and the new clause is written to keep it that way.

Two more pins: the gate ADMITS this address under `open` with no invitation at
all — which is what shows the posture is not what stops an existing person,
since whatever refuses them sits downstream of it — and the message states the
mechanism rather than a status code.

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

@@ -6,7 +6,7 @@ The `no_sign_in_account_at_boot` report now names a remedy that works — and wa
 
 That boot line fires on the deployment nobody can sign in to: human `sys_user` rows, zero `sys_account` rows. It ended with two remedies, and measured on the exact population it fires on, neither did what its sentence said:
 
-- **"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.
+- **"Open the audience posture so an existing person can register their own login"** produced no login, and for an existing person it never can: self-registration is a user-creation path, so it cannot attach a login to an address that already carries a `sys_user` row, whatever the posture. Widening only ever admits a *new* address — and then every posture other than `invite_only` forces `requireEmailVerification` on, so that login 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 — 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.

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

@@ -399,6 +399,28 @@ describe('#15588/F1 — the carve-out ADMITS, it does not EXEMPT: the rider\u201
   });
 });
 
+describe('#15588 — remedy (b) cannot recover an EXISTING person, and the posture is not the lever', () => {
+  it('under `open` the gate ADMITS the address outright — so the posture is not what stops them', () => {
+    // The message says widening "cannot recover an EXISTING person at all …
+    // and NO posture changes that". This is the half that shows WHY the
+    // posture is not the lever: the audience gate is a CREATION gate and it
+    // already says yes for this address with no invitation at all. Whatever
+    // refuses an existing person therefore sits DOWNSTREAM of the posture, so
+    // moving the posture cannot reach it — which is exactly what the message
+    // now tells the operator, instead of sending them to widen it.
+    expect(invitedSignUp('open', false)).toMatchObject({ admit: true });
+  });
+
+  it('the message states it in MECHANISM terms — the operator is told WHY, not a status code', () => {
+    const msg = resolveNoSignInAccountReport(DEAD_END)!;
+    expect(msg).toContain('cannot recover an EXISTING person at all');
+    expect(msg).toContain('user-CREATION path');
+    expect(msg).toContain('NO posture changes that');
+    // and the half that IS about a new address survives beside it
+    expect(msg).toContain('Widening only ever admits a NEW address');
+  });
+});
+
 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

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

@@ -63,13 +63,22 @@
  *    that would move #14353's diagnostic semantics. The message tells the
  *    truth about today's probe instead, and the pin fails the day the probe
  *    changes — which is the day this sentence must be rewritten.
- *  - **Widening the posture forces email verification on.**
+ *  - **Widening the posture cannot recover an EXISTING person at all, and
+ *    only half-works for a new one.** The operator reading this line is
+ *    usually trying to recover somebody the directory already holds, and for
+ *    them the posture is not the lever: self-registration is a user-CREATION
+ *    path, so it cannot attach a login to an address that already carries a
+ *    `sys_user` row, whatever the posture — the audience gate ADMITS such an
+ *    address under `open` (pinned), which is precisely why moving the posture
+ *    cannot reach what refuses them. ⚠️ Stated in MECHANISM terms on purpose:
+ *    what that refusal answers on the wire is #15587's surface, in flight, and
+ *    this line must stay true on both sides of it — a pin holds it there.
+ *    For a NEW address, widening does create the account, and then
  *    `audiencePermitsSelfRegistration(posture)` drives `createAuthInstance()`
  *    to wire `requireEmailVerification: true` (mirrored by
- *    `getPublicConfig()`), so a login registered under `open`/`email_domain`
- *    is refused `EMAIL_NOT_VERIFIED` at first sign-in — no login at all on a
- *    deployment with no mail transport, which is the shape a locked-out
- *    self-hosted install usually is.
+ *    `getPublicConfig()`), so that login is refused `EMAIL_NOT_VERIFIED` at
+ *    first sign-in — no login at all on a deployment with no mail transport,
+ *    which is the shape a locked-out self-hosted install usually is.
  *
  * The message deliberately does NOT describe what a SEEDED person's own
  * re-registration answers: that response is #15587's surface and is being
@@ -285,8 +294,11 @@ export function resolveNoSignInAccountReport(facts: SignInReachabilityFacts): st
     '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') " +
-    'FORCES email verification ON, so a login registered that way is refused EMAIL_NOT_VERIFIED at ' +
+    'OPENING THE AUDIENCE POSTURE — which cannot recover an EXISTING person at all: ' +
+    'self-registration is a user-CREATION path, so it cannot hand a login to somebody whose ' +
+    `'${SystemObjectName.USER}' row already exists, and NO posture changes that. Widening only ever ` +
+    "admits a NEW address — and then every posture other than 'invite_only' ('open', " +
+    "'email_domain') FORCES email verification ON, so that login is refused EMAIL_NOT_VERIFIED at " +
     'its first sign-in until a mail transport delivers the link, and a locked-out self-hosted ' +
     'install usually has none. Nothing here happens by itself.'
   );