fix: validate base64-prefixed chunked cookies decode to valid JSON

[mandarini]

Summary

Adds defensive validation to chunked cookie decoding so corrupted or mid-write cookie state no longer propagates a malformed string into @supabase/auth-js. When a value is read via the chunked cookie path and carries the base64- prefix written by this module, the decoded payload is now verified to be valid JSON (which it always must be, since setItemAsync in auth-js writes via JSON.stringify). On decode or parse failure we log a console warning and return null, signalling the entry is absent so the SDK can recover cleanly instead of crashing or re-saving garbage.

What changed

• New decodeChunkedCookieValue helper in src/cookies.ts, used by both the browser and server getItem paths inside createStorageFromOptions.
• The helper:
  • Returns the value unchanged when there is no base64- prefix (raw cookies and PKCE code verifier paths are unaffected).
  • Catches throws from stringFromBase64URL and warns: "could not base64url-decode chunked cookie value..."
  • Validates the decoded value parses as JSON; on failure warns: "chunked cookie decoded to invalid JSON..."
  • Returns null in either failure case.
• Both getItem paths in createStorageFromOptions now delegate to this helper.
• Four new tests in src/cookies.spec.ts covering: invalid JSON in decoded chunks, valid JSON in decoded chunks, undecodable base64url payload, and that raw (non-base64) cookies are passed through without JSON validation.

Why

Reported in #169 with a complete root cause analysis from the original reporter. When a session is large enough to span 3+ cookie chunks (sb-...auth-token.0/.1/.2/...) and a server side refresh writes only some of the new chunks (e.g. response committed before all Set-Cookie headers go out, partial set/remove during SSR, browser racing concurrent navigations), the browser ends up holding chunks from two different generations. combineChunks joins them blindly and there are two failure modes downstream:

1. Combined bytes happen to all fall in the base64url alphabet. stringFromBase64URL succeeds, but the decoded result is garbage that fails JSON.parse later in auth-js. Before the auth-js companion fix, this produced a TypeError: Cannot create property 'user' on string ... in _recoverAndRefresh and embedded the access token JSON in the error message (token leaked into application error logs).
2. Combined bytes contain a character that is invalid in base64url, e.g. a . from a raw JWT segment that landed in a chunk. stringFromBase64URL throws synchronously: Invalid Base64-URL character "." at position N. This surfaces as an unhandled rejection in production and was reported separately by another customer hitting the same root cause class.

This change catches both failure modes at the source so they never reach auth-js. The corresponding auth-js change (supabase/supabase-js#2312) is the primary fix for the user visible crash from variant 1; this PR is defense in depth and is the actual fix for variant 2.

Notes for reviewers

• The JSON validation is intentionally narrow: it only runs when the value carries the base64- prefix that this module itself writes. Raw cookies (cookieEncoding: "raw"), and any cookie value that does not carry the prefix, are returned unchanged. This keeps the change safe for users storing non-JSON values via the storage interface and for the PKCE code verifier path.
• The helper is reused by both the browser and server getItem. The server path retained its existing typeof chunkedCookie !== "string" defensive shortcut for cases where combineChunks might return a non-string at runtime.

Tracking

• Closes TypeError in _recoverAndRefresh when large session cookie chunks become corrupted #169
• Closes Invalid Base64 characters in auth-token crashes server #87
• Refs fix(auth): return null from getItemAsync on JSON parse failure supabase-js#2312 (the auth-js companion fix that prevents the TypeError on the path before this PR's defenses)