Flightdeck hardcodes its Site lookup to the posit-team namespace

Summary

Flightdeck's readiness/Site lookup targets the posit-team namespace regardless of where its Site actually lives. For a Site deployed in any other namespace, flightdeck fails readiness forever.

Observed live on the pwb-team-operator EKS cluster (operator chart v1.22.0, 2026-07-08) with a Site named pr-11608 in namespace pr-11608:

level=ERROR msg="failed to fetch site" name=pr-11608 namespace=posit-team
  error="sites.core.posit.team \"pr-11608\" is forbidden: User
  \"system:serviceaccount:pr-11608:pr-11608-flightdeck\" cannot get resource
  \"sites\" in API group \"core.posit.team\" in the namespace \"posit-team\""
level=WARN msg="readiness check failed" ...

Note it queries namespace=posit-team even though the Site (and flightdeck's own RBAC, correctly scoped by the operator) are in pr-11608 — so the pod sits 0/1 Running indefinitely.

Context

With WATCH_NAMESPACES widened, the operator reconciles Sites in arbitrary namespaces (we run ephemeral per-PR Workbench preview Sites in pr-<n> namespaces — rstudio/rstudio-pro#11587). Everything else (workbench, per-Site database, storage, ingress) works namespaced; flightdeck is the one product that assumes posit-team.

Expected

Flightdeck should resolve its Site in its own namespace (e.g. from the downward API / its deployment's namespace) rather than a hardcoded posit-team.

Workaround

spec.flightdeck.enabled: false on non-posit-team Sites.

Locate Flightdeck's readiness/Site lookup and search for the hardcoded posit-team namespace. Read how the deployment's namespace is exposed through the downward API, then update the lookup to use the Site's own namespace. Done means a Site in a non-posit-team namespace passes readiness instead of failing on an unauthorized lookup.