web/admin/space bundles call /pi/api/v1/flags/ and /pi/api/v1/chat/start/auth-check/ unconditionally, producing console 502s when PI_API_REPLICAS=0 (the default)

Related: #8254 — same root cause, closed without fix. Maintainer's response there confirms AI/Pi isn't released for self-hosted, yet the frontend still calls the endpoints. The behavior has gotten broader in v2.6.1: instead of only firing on chat-sidebar activation (as in v2.0.0), the flag and auth-check endpoints fire on every workspace load.

Environment

Plane Commercial Edition v2.6.1, self-hosted via prime-cli setup --silent --behind-proxy --domain=<...>
Ubuntu 24.04, Docker Compose, single VM
Behind a reverse-proxy (TLS terminates upstream); Plane's --behind-proxy mode
Default Pi config — PI_API_REPLICAS=0 (vendor default), no LLM keys, no OpenSearch deployed
Observed

On every workspace navigation, browser devtools shows two failed requests:

GET /pi/api/v1/flags/?workspace_slug=&is_guest_user=false → 502
GET /pi/api/v1/chat/start/auth-check/?workspace_id= → 502

[Error fetching AI feature flags] (from store-context-.js)
Origin of the 502: plane-proxy routes /pi/* to pi-api:8000, but pi-api isn't running (PI_API_REPLICAS=0 default) and Docker DNS returns NXDOMAIN:

$ docker exec plane-proxy-1 wget -qO- http://pi-api:8000/api/v1/flags/
wget: bad address 'pi-api:8000'
Why this matters (beyond cosmetic noise)

Self-hosted operators see scary 502s + "Error fetching AI feature flags" every workspace load. Hard to distinguish from real outages.
Synthetic monitoring (uptime checks, WAFs like CrowdSec) trips on the 5xx volume.
We saw a real perf symptom too: intermittent timeouts on /pi/* (via a slower upstream) made workspace switching feel sluggish — a "blink" where UI state reset on every navigation. Replacing the 502 with a 200 {} at our reverse proxy eliminated it.
Expected

Frontend should not call /pi/* when Pi isn't deployed/enabled. Either:

Expose a pi_enabled boolean from /api/instances/ (or similar non-Pi endpoint) and gate all frontend Pi calls behind it.
Have plane-proxy stub /pi/* internally (return {} 200 or 204) when pi-api isn't routable — frontend already handles a non-200 gracefully, just needs the right shape.
The graceful-degradation logic is already in the frontend (the page renders fine after the 502). The only thing wrong is the signal shape: a 502 is misleading; a 200-empty would be clean.

Repro

Install Plane Commercial v2.6.1 via prime-cli with vendor defaults.
docker ps | grep pi-api → empty.
Open any workspace in the UI.
Devtools → Network/Console: observe 502s + console errors.
Workaround we're using

Traffic to /pi/* is trapped at our upstream Caddy and answered with {"":""}... actually just {}. The frontend reads the empty JSON, decides AI is disabled, renders cleanly. Works perfectly but it's a band-aid that every self-hosted operator has to invent independently.

Suggested fix (in maintainer's order of effort)

Smallest: plane-proxy Caddyfile gets a handle /pi/* { respond "{}" 200 } when PI_API_REPLICAS=0 (detectable at Caddyfile-template time via env var, similar to how --behind-proxy is wired).
Right one: surface pi_enabled: false from /api/instances/ and gate the frontend's Pi calls on it.

(yes AI Generated, but it's real)