fix: docs proxy gating, register session, password-reset enumeration

[glennmichael123]

Closes #2213, #2212, #2214. Three independent fixes, one branch — each is a few lines and they touch disjoint files.

---

#2213 — /docs proxy was unconditional

dev/views.ts proxied /docs ahead of page routing with no existence check, so an app with its own resources/views/docs.stx could never serve it, and an app with no docs site got a proxy to a dead port instead of a 404.

The costly part is that buddy serve has no /docs branch at all — it just resolves the page route. Dev and production disagreed about what /docs is, so the page that ships was the one nobody could review locally.

Now: a userland page wins outright; the proxy runs only when a docs/ site exists; otherwise /docs falls through to normal routing, which turns the dead-port case into an ordinary 404. Resolved once at startup — both checks are filesystem stats and the answer can't change without a restart.

Verified all five combinations (docs site only, docs.stx only, docs/index.stx only, both, neither) — 5/5.

---

#2212 — registration minted a session and discarded half of it

register() called Auth.createToken(), a wrapper that mints a refresh token and expiry and throws both away. So the action had nothing but an access token to return.

The issue reasoned that both endpoints call loginUsingId() — they don't; register() never did. The root is one layer lower, which is where this fixes it: register() now uses createTokenForUser and returns the same triple loginUsingId() does. Additive, so const { token } = await register(...) is unaffected.

With tokenExpiry defaulting to one hour, a client that correctly stores the pair worked for everyone except the user who had just signed up.

---

#2214 — password reset was an account-existence oracle

404 "No account found with this email address." vs 200, unauthenticated, with rate limiting keyed per-email — so it doesn't slow enumeration across addresses at all.

Three things had to change, not one:

1. the 404 becomes the neutral 200
2. a failed job dispatch also returns the neutral 200 — this is the trap the issue flagged. Returning 500 rebuilds the oracle whenever the mailer is degraded, since an unknown address never reaches dispatch and so can never 5xx
3. the console.log trail is gone — it echoed the submitted address at four points, putting user emails into framework-default logs

The message lives in one constant because the property is that every branch returns it byte for byte.

Not addressed: a known address does strictly more work (a queue dispatch), so a timing signal remains. That needs its own change, and it's a far weaker oracle than a 404 with an explanatory message.

---

Verification

• auth: 258 pass, 0 fail. One test legitimately needed updating — it mocked Auth with only createToken, and asserted { token } alone; both now reflect the full session.
• pickier clean, framework + app typecheck clean.

One incidental finding: pickier's no-unused-vars mis-reads a multi-line return-type annotation and flagged the still-used credentials parameter. Worked around by naming the type (RegistrationResult), which is better anyway, but it's a real false positive worth a separate report.

🤖 Generated with Claude Code