fix: Control Center iframe auth + false setup banner

[man4ish]

Context

Tonight's investigation into webstudio.omnibioai.org's embedded Control Center panel found two independent, unrelated root causes. This PR fixes both, as two separate commits.

FIX 1 — nginx missing Authorization forwarding (5dfdd31)

/_svc/control's gated location correctly validated the request via auth_request (using $control_authorization, a cookie-fallback for iframe navigations, added Jul 29 in 1329fed5) — but never forwarded that resolved header on the actual proxied request to control-center:7070. It only forwarded it to the internal /auth/verify subrequest used for the gate check. control-center's own require_permission() then independently 401'd the header-less request with "Missing or malformed Authorization header". /_svc/toolserver already had the correct pattern (proxy_set_header Authorization $control_authorization; on its own proxy_pass, not just the gate) — /_svc/control was just missing the equivalent line.

Not related to tonight's PR #77/#78 — neither touched GET / (what the iframe loads), which stayed gated throughout both. The real chain: Jul 29 added the cookie fallback but only wired it into the gate subrequest (harmless then, since GET / had no backend auth yet) → Sept 1's 8705cbf (an unrelated control-center route audit) gated GET / for the first time, which is what first exposed this dormant gap.

Before → after (real access token from a real /auth/login call, not synthetic):

/_svc/control/ (with cookie):        401 {"detail":"Missing or malformed Authorization header"}  →  200, real HTML
/_svc/control/ (no cookie):          401 (unchanged — nginx's own @cc_unauthorized gate)
/_svc/control/docker/containers:                                                                    200 with cookie
/_svc/control/{knowledge-base,storage,cron/jobs,coverage/status}:                                    200 with cookie
/_svc/control/{health,summary,report,report/data} (public allowlist, byte-for-byte untouched):        200/401/401/200 — identical to before

Deployment note surfaced along the way: a plain nginx -s reload did not pick up the edit. nginx-router bind-mounts the config as a single file, pinned by inode at container-create time — an editor's atomic rename-on-save orphans that mount from any later host-side edit, permanently, regardless of how many times nginx reloads afterward. Required docker compose up -d --force-recreate nginx-router (this one container only) to actually apply the change. Confirmed via stat -c '%i' inode comparison before concluding this, not guessed.

FIX 2 — wire the existing web-mode config shim, remove the false "Setup required" banner (e6059d6)

App.jsx's header banner fires whenever config.settings.data_dir is unset — an Electron-only concept (the local Docker stack's data directory, read via window.api.loadConfig()). On web (no window.api), that whole branch was skipped, so config never left its hardcoded default — the banner showed unconditionally for every web visitor, nothing actually misconfigured.

src/ui/lib/web/webApi.js already had a loadConfig() built for exactly this, explicitly documented as unwired. Two changes were needed (wiring the call in alone would not have changed anything visible — its return shape is identical to the existing hardcoded default):

1. Call webApi.loadConfig() when !isElectron() (existing helper, same one ServiceViewer.jsx already uses) — no first-run redirect for this path, unlike Electron's.
2. Gate the banner on config.mode !== "beta" too — "beta" is this codebase's existing "no local Docker" signal (Launch.jsx/Services.jsx's isBeta), correctly covering both the web deployment and choosing "Beta" inside Electron itself.

Electron's own branch is untouched (confirmed by diff). Grepped src/ui/ for every config.settings reader — only these two call sites exist.

Verified in the actual deployed production bundle (rebuilt + redeployed web-ui), not just source:

o?.mode!=="beta"&&!o?.settings?.data_dir&&(...⚠ Setup required — configure data directory...)

config.mode defaults to "beta" on web both before and after this change, so the banner no longer renders.

Testing

• npm run test:ui (full suite): 28 files, 198 tests, all pass — including tests/ui/app-shell.test.jsx's own first-run-banner test (Electron, mode: "local", no data_dir → banner still expected and still shown).
• Both fixes verified live against the running omnibioai-studio stack (see curl output above), not just unit tests.

Not merging — opening for review, per the explicit ask.

🤖 Generated with Claude Code