A proxy's 404 is not the relay's answer: un-latch token minting on 401

Same fix as iOS: RelayAuth latched 'no token endpoint' off one 404, and
an outage's proxy-level 404s wedged the client into tokenless requests.
invalidate() now un-latches — the 401 is proof the conclusion was wrong.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

client/src/main/kotlin/io/flamenet/client/RelayAuth.kt

@@ -65,8 +65,22 @@ class RelayAuth(
         return minted.token
     }
 
-    /** Discard the cached token, so one stale token costs a single retry. */
-    fun invalidate() { cached = null }
+    /**
+     * Discard the cached token, so one stale token costs a single retry.
+     *
+     * 🔴 **Also un-latches [unavailable].** That flag is a told-once marker: it
+     * concludes "this deployment has no token endpoint" from a single 404 — but
+     * a reverse proxy answers 404 for *every* route while the relay behind it
+     * is down, so an outage at the wrong moment latched it against a relay that
+     * does issue tokens, and every request thereafter went out with no token at
+     * all. The 401 that brings callers here is direct evidence the conclusion
+     * was wrong: a deployment that didn't want tokens would not refuse us for
+     * lacking one.
+     */
+    fun invalidate() {
+        cached = null
+        unavailable = false
+    }
 
     /**
      * The proof headers for one request.