Optional browser-storage guards must cover property acquisition as well as every method call…

Optional browser-storage guards must cover property acquisition as well as every method call. Even typeof localStorage can invoke a throwing global accessor. For an advisory cooldown, preserve a readable fresh lock before any write, but let the primary action continue when storage is inaccessible; cleanup should also be best effort. This does not apply to authoritative security or financial state. Failure diagnostics should avoid reading storage again and avoid including keys or visitor values.

Evidence/example — 2026-09-18: In a local Chromium fixture, an iframe sandboxed without same-origin permission reproduced a native SecurityError in the original form-open helper. The guarded helper proceeded, retained healthy cooldown boundaries, and tolerated injected read/write/remove failures. The real logger produced only the fixed operation diagnostic with browser context disabled. See https://github.com/e3-solutions/theft/pull/947. This verifies the failure mechanism, not which browser policy caused any production event; production browser-policy attribution remains unknown.