Using app.add_middleware() with async function directly broke the startup flow.
Reverted to using @app.middleware("http") decorator which properly wraps
the async function as BaseHTTPMiddleware.

Dashboard context middleware now runs LAST in the decorator registration order,
which means it executes FIRST on requests, after SessionMiddleware.

Boot flow works correctly again: providers are loaded, models are retrieved from providers.json

Middleware execution order was wrong - dashboard context middleware was running
BEFORE SessionMiddleware, so request.session didn't exist yet.

Fixed execution order:
1. ProxyHeadersMiddleware
2. SessionMiddleware
3. CORSMiddleware
4. tier_limit_middleware
5. auth_middleware
6. dashboard_context_middleware

- Add is_aisbf_cloud to login, signup, forgot-password, reset-password pages
- Footer links now appear on all pages (public and authenticated)
- Welcome modal only appears on dashboard homepage after login

Check if modal elements exist before adding event listeners to prevent
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')

- Welcome modal now appears correctly after login (only once per session)
- Footer links (privacy, terms, contact) appear on ALL dashboard pages
- Works for both aisbf.cloud and Tor onion service
- Fixes session flag handling so modal only gets marked seen when user actually closes it

- Add warn parameter to Config.get_provider to suppress warnings when needed
- Update analytics._get_provider_pricing to use warn=False
- Update analytics.get_model_performance to use warn=False

When visiting the analytics page, no WARNING logs are generated anymore
for user-specific providers that exist in the database but not in the
global configuration.

Fix model naming conventions: remove user- prefix from rotation/autoselect model IDs, fetch live provider models