Take cklib out of the token path — tokenProvider / inject-nc; retire login

[styk-tv]

Take cklib out of the token path. cklib currently owns auth: CKClient.login(user,pass) does a direct password grant, holds the token, refreshes, reconnects. With identity server-derived (#12), the client should never mint, hold, or validate a token.

Proposal — two modes

• Mode A — forward-only: CK.activate('pgCK', { wssEndpoint, tokenProvider: async () => jwt }). cklib forwards the app-supplied token into the NATS CONNECT frame and re-invokes on refresh; it never mints, stores, or validates it. The substrate validates at the admission boundary; a bad/expired token is refused.
• Mode B — inject-nc (target): CK.activate('pgCK', { nc }). The app builds + authenticates its own NATS connection and injects it; cklib does dispatch/subscribe only and never touches the token. k.close() detaches subscriptions, not the connection.
• Retire login(user,pass) from the L2 story (legacy only). No token → anonymous.

Dependency

None on pgCK — the substrate already validates the presented token at admission and supports anonymous. Client-side only; can proceed independently.

Done-when

• No password grant / token mint / token storage in the cklib dispatch path.
• Mode A forwards + reconnects on refresh (browser + CLI); Mode B injects with correct lifecycle.
• Docs updated (auth model in SPEC.CK-LIB-JS / SPEC.CK-OPERATIONS / GUIDE).

Relates

• Partner axis: Derive dispatch identity server-side — retire the client-built id-segment #12 (identity subject). Enables Unified server-derived participant presence — client surface (query + events) #13 over one shared connection.

[styk-tv]

This issue splits on dependency — Mode A is startable, Mode B is blocked

The body reads "Dependency: None on pgCK — client-side only; can proceed independently." That is true for Mode A and false for Mode B.

Mode A (tokenProvider) — no dependency, startable now. cklib receives the app-supplied token and can decode it exactly as login() already does, so auth.claims and the id-scoped subject survive. Nothing on the substrate side is required.

Mode B (inject-nc) — blocked, and not merely gated. With an injected connection cklib never sees a token, so this.auth stays at its constructor default (no claims key), the id-segment resolves to null, and the dispatch falls back to the plain subject — which seals anon. styk-tv/pgCK#11 independently confirms this and rules that no replacement attribution mechanism is planned, so there is currently nothing to gate Mode B on.

Acceptance-test gap: Done-when has three bullets and none mentions created_by. Mode B can satisfy all three while regressing what 1.5.6 achieved. A fourth bullet is needed — created_by unchanged for a verified connection in both modes — before Mode B is implementable at all.

Scope is being added as a distinction, not removed (C2): no work is dropped, Mode A proceeds, Mode B acquires an honest precondition.