openfut-protocol-blaze: pin advertise/bind so fixtures do not depend on the shell

The responder reads OPENFUT_ADVERTISE/OPENFUT_BIND at import time and several
live payloads embed the advertised address (Blaze redirect target, RS4/POW/
roster URLs). Without pinning, regenerating on a machine that exports
OPENFUT_ADVERTISE produces different bytes and --check goes red for a reason
that has nothing to do with the codec.

Pinned to 127.0.0.1 as a placeholder so no real LAN address is baked into a
committed fixture. Not a claim about deployment: remote mode still requires an
explicit advertised address and has no loopback fallback.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

openfut-protocol-blaze/fixtures/generate.py

@@ -55,6 +55,21 @@ sys.path.insert(0, TOOLS)
 # staleness guard into a no-op that always rewrites and always passes.
 CHECK_ONLY = "--check" in sys.argv[1:]
 sys.argv = [sys.argv[0]]
+
+# Pin the deployment-dependent config BEFORE importing the responder, which
+# reads these at import time. Several live payloads embed the advertised
+# address (Blaze redirect target, RS4/POW/roster URLs), so without this the
+# fixture bytes would depend on whoever's shell ran the generator and `--check`
+# would go red on a machine that happens to export OPENFUT_ADVERTISE.
+#
+# 127.0.0.1 is a placeholder chosen so no real LAN address is ever baked into a
+# committed fixture. It is NOT a statement about how the backend is deployed —
+# remote mode requires an explicit advertised address and has no loopback
+# fallback (see the vault's Architecture note on OPENFUT_BIND vs
+# OPENFUT_ADVERTISE).
+os.environ["OPENFUT_ADVERTISE"] = "127.0.0.1"
+os.environ["OPENFUT_BIND"] = "127.0.0.1"
+
 import heat2  # noqa: E402
 import blaze_responder_v3b as B  # noqa: E402