fix(mcp): authenticated queries never worked — and the auth knob shouldn't exist

[zzstoatzz]

two commits: query(authenticated=True) has failed 100% of the time since it shipped (JWT read from client.me, which has no access_jwt — every call raised AuthenticationRequired after a successful login, blaming missing credentials), and the fix exposed that the authenticated kwarg itself was a smell: the allowlist already fully determines which NSIDs need the session, so auth is now automatic and the flag is deprecated-and-ignored.

commit 1 — the bug (d5a7592)

• phi's self-trace audit surfaced 22 identical failures on a ~4h schedule going back a month — a 100% failure rate, not an intermittent one
• reproduced against the hosted server and against current main locally
• a credentials spy showed handle/password present and login succeeding — the failure was getattr(client.me, "access_jwt", None) returning None; the JWT lives on client._session (a Session dataclass)
• after the fix, a live local run returned real notifications through the authenticated path
• the existing test never caught it because its fake client put the jwt on .me — the fake now matches the real SDK shape

commit 2 — the smell (8ea37aa)

• the caller-supplied authenticated flag was a redundant degree of freedom: the server already fully determines auth need from the NSID (the allowlist), and both allowlisted endpoints are auth-only
• for LLM callers the flag was a knob to guess at, with a misleading failure mode when guessed wrong
• now: allowlisted NSIDs authenticate automatically; everything else is always public — no caller-supplied knob can widen the boundary (regression-tested: a non-allowlisted NSID never touches credentials even with authenticated=True passed)
• the kwarg is kept and ignored so existing callers don't fail schema validation; drop it in a later major

🤖 Generated with Claude Code