The gate removed `Authorization` unconditionally before proxying, so every
credential an app owns was destroyed one hop before the app saw it.
IndeeHub's Nostr login is the reported case: it signs a NIP-98 event and
sends `Authorization: Nostr <event>` to its own /api/auth/nostr/session.
The header arrived stripped and its backend answered "Authorization header
is missing" — a 401 that no signer could ever satisfy. That is why a NIP-07
browser extension in a tab, the parent frame's NIP-07 bridge
(nostr-provider.js) and AIUI all broke at once while the signing itself was
never at fault. Proven on the node: the same POST returns a real NIP-98
validation error on loopback and the gate's login page through the gate.
The gate accepts exactly one header credential — `Authorization: Bearer
<app-scoped device token>` — so only that one is ours to withhold. authorize()
now reports which credential allowed the request, and the header is dropped
only when it WAS the gate's token, mirroring the surgical cookie strip
directly above it. Any other scheme (Nostr, Basic, an app's own bearer)
rides through untouched.
Credential-less allowlist paths still drop the header: nothing there needs
auth, so an unverified token is not handed to the app.
Tests: an app's Authorization is not classified as the gate's, and a real
proxy hop against a local server shows the app's credential arriving intact
while a gate device token does not.