fix: tolerate unavailable browser environment storage

[MathiasWP]

Fixes #131.

When a browser exposes localStorage but getItem() throws, the top-level environment flag checks can prevent lib0/environment from loading. Catch browser storage read failures in getVariable() and return null, matching a missing flag. The Node environment-variable path is unchanged, and later successful storage reads still work.

Adds tests to the existing runner for import-time NS_ERROR_FAILURE/SecurityError, readable and missing values, temporary storage failure followed by recovery, and Node variable normalization. Browser initialization is exercised in isolated Node subprocesses with browser globals set before importing the real modules. The new failure tests fail against the previous implementation.

The production report was on 0.2.117; this PR targets the current ESM-only main branch.

Validation:

• node src/test.js --filter 'environment:'
• npm test (including coverage thresholds)
• npm run lint (JSDoc types, Standard style, circular imports)

[MathiasWP]

Would be nice to get pushed in, after investigation this error is the cause of a Sentry alert we got in production: https://kvist.sentry.io/share/issue/7d30a4d50deb40ccb082dd57470640ab/

The alert is really random, and there no good traces because this library is a dependency in TipTap's dependency chain 👀

[MathiasWP]

@dmonad is this something that seems reasonable to add into a new release of lib0?