Signed fetches to static hosts fail CORS preflight; retry unsigned on network error #33

What happens

On a trusted origin, Podkey adds a NIP-98 Authorization header to every fetch (src/nip98-interceptor.js). That header makes the browser send a CORS preflight (OPTIONS) before any cross-origin request. Static hosts such as GitHub Pages don't answer preflights, so the request fails before it starts, even for public files that need no auth at all.

Seen with mindstr.org opening a public map from GitHub Pages, while logged in with Podkey and with melvincarvalho.github.io trusted:

Access to fetch at 'https://melvincarvalho.github.io/mindstr-maps/maps/sugar.json' from origin 'https://mindstr.org'
has been blocked by CORS policy: Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

The same request without Podkey (or logged out) returns 200 with access-control-allow-origin: *. The page can't avoid it: the interceptor wraps window.fetch itself.

Suggested fix

In window.fetch's wrapper (next to the existing 401 retry): if the signed request throws (a network/CORS failure, TypeError: Failed to fetch) and it was a GET or HEAD that Podkey signed (the page didn't set its own Authorization), retry once without the header and return that result.

• Public files on static hosts then load for logged-in users.
• Auth isn't weakened: a server that needs auth answers 401, and the existing 401 retry still signs.
• Only safe methods are retried, so nothing is sent twice that could change state.

The same applies to the XHR path.

Possibly also

isTrustedOrigin matches subdomains (hostname.endsWith('.' + trusted)), so trusting github.io would sign requests to every GitHub Pages site. It might be worth not allowing that for shared hosting suffixes, or saying so in the UI.