fix: fall back to memory when browser storage access is denied

[ItsM0rty]

With cookies: { encode: "tokens-only" }, createBrowserClient() reads window.localStorage to choose where to store user data. That property can throw a SecurityError when browser policy blocks storage access. Client creation then fails before auth can use the cookie adapter.

This catches failures when obtaining the default browser storage and uses a fresh memory adapter instead, matching the existing non-browser fallback. Accessible localStorage is still used, and an explicit auth.userStorage takes precedence without touching localStorage. Tokens continue to use cookie storage. The option documentation explains that fallback user data lasts only for the lifetime of the client.

The regression uses a localStorage getter that throws a DOMException. It fails on the original implementation and passes with the fix. It also checks user storage read/write/removal, cookie-backed token storage, explicit userStorage, and the normal browser path.

All 123 tests pass across seven files. Both TypeScript builds, Prettier checks, and whitespace checks pass. This was tested in Node 22 with a simulated browser storage denial; a browser automation test was not run.