Release 0.26.2: restore existing client tokens without rotation

[zackbart]

Connecta 0.24 removed managed client tokens, preventing deployments with active v0.23 credentials from upgrading. This patch restores them through the optional @zackbart/connecta/auth/access-tokens module and prepares version 0.26.2, including the changelog and Node template pin.

Existing cta_… secrets authenticate against the original access-token:v1:record:* and lookup records without rewriting storage or rotating clients. Token IDs, activity labels, and principal bindings survive. Every request still uses the deployment's current identity/tool/pool grants.

To upgrade, import accessTokens, replace the old boolean/options configuration with accessTokens: accessTokens(storage), and retain the same storage namespace and grant rules. The operator UI restores create/show-once/list/rename/revoke behind the new, denied-by-default identity.accessTokenManagement permission. Static and managed bearers cannot administer tokens or connection credentials. Omitting the module loads no token implementation into core, and the eight MCP tools stay unchanged.

New issuance requires atomic compareAndSet storage to bound concurrent creation. Legacy adapters still verify existing tokens and support rename/revoke; revocation follows the backend's consistency guarantees. Uncertain writes retain their capacity reservation, and atomic metadata updates prevent a stale rename from erasing revocation.

Validation: npm run release:check passed, including 4,785 tests across Node and Workers, 50 Chromium tests, declaration/import/bundle checks, zero runtime audit vulnerabilities, package installation, and Docker smoke. A fixture generated by the actual v0.23 manager covers original valid/revoked secrets and principal bindings. The installed release tarball also passed connecta doctor with an original fixture token and real QuickJS. Browser coverage exercises the real lifecycle routes, one-time display, rename, reload, and revocation.

Closes #619.