Feature/global app scaffold

[imenattatra]

Closes https://github.com/metr-systems/backlog/issues/4906

AI Disclaimer: yes claude , in the poc i relied on it a lot but for this i had to study the webpack configuration and check details what we are doing

Summary

This PR introduces an initial Redash Global (redash_global/), a second Flask app that will host the cross-organization Global Dashboard Management System. It shares the same PostgreSQL database as the main Redash app but runs as its own process on its own port.

Right now it does exactly one thing: serve a single React page that says "Work in progress" : no API, no auth, no data models, no CLI. It's a clean, minimal starting point to build the real admin UI on top of.

You can see it live on staging: https://global-dashboard.staging.metr.systems/ , knowing that i needed also to deploy changes in this infrastructure PR to make it work https://github.com/metr-systems/infrastructure/pull/84/changes

What's added:

Backend :
- create_global_app() factory that reuses Redash's settings and DB, registers one blueprint with a single / route that serves the webpack-built global.html.
- A wsgi_global.py entrypoint for gunicorn.

Frontend :
- a React entry (index.js) that mounts a self-contained GlobalApplicationArea placeholder into #application-root, plus a minimal global.html template.

Build & run wiring :
- a new webpack entry (global_app) + HtmlWebpackPlugin that build the global bundle and its global.html page
- a global_server docker-entrypoint command (gunicorn on port 5001)
- and a Dockerfile line to copy redash_global/ into the frontend build image.

Code Strategy

• Shared database, separate app
• Served at /
• Not exposing anything for now
• Very minimal frontend for now
• Same webpack pipeline as main app, there is only one point of difference and only for the devserver (explanation follows)

How the main app works in dev: You run yarn start, which launches the webpack dev server on :8080. That server keeps all the built bundles in memory and serves them straight to the browser, nothing is written to dist/ on disk. The browser talks directly to the dev server, and API calls are forwarded to the real Redash backend via the proxy rules. This is what makes hot-reloading fast: rebuilds stay in memory, no disk I/O.

we could have proxied the global app through the dev server too (like the main app's proxy rules), but that only makes sense once the global app has an API and needs hot-reload through :8080 , which the current bootstrap doesn't. Serving from disk is the simplest thing that lets the separate Flask process work today, and the dev-proxy route stays open for later

• Serves its own static assets from dist/ and runs as a gunicorn process on port 5001 (new global_server entrypoint command)

QA

How did you test it? Keep your future self in mind to help debug things later.

• Manually, on staging , you can see it here https://global-dashboard.staging.metr.systems/

[helenalebreton]

@imenattatra I have seen your PR but I cannot really review it.