Build a read-only ops dashboard on top of an existing production database

Build Ops Console, a read-only internal dashboard on top of an EXISTING production database — you are not designing the data model, you are visualizing one that already exists and must not be altered.

EXISTING SCHEMA
The dashboard reads from these tables, exactly as they exist today — do not rename a column, do not add a migration, and do not assume a field exists that isn't listed here:
orders(id, customer_id, status, total_cents, created_at), customers(id, email, name, created_at), order_items(id, order_id, sku, qty, unit_price_cents) — Postgres 15, orders.customer_id references customers.id, order_items.order_id references orders.id

CONNECTION AND ACCESS
Connect using a read-only database role or a read replica connection string, never the primary write credentials — use the read-only reporting replica connection string in an env var named REPORTING_DB_URL, not the primary DATABASE_URL. If Lovable's setup flow only offers a single connection string with write access, explicitly note that risk back to me rather than silently proceeding, since this dashboard should be structurally incapable of writing to production even if a bug in the generated code tried to.

WHAT TO BUILD
1. A landing view: orders today, gross revenue this week, average order value, count of orders still in pending status, each as a card with the current value and a simple trend indicator against the prior period.
2. the orders table — a filterable, sortable table view over the real data, with pagination; assume the table can hold hundreds of thousands of rows, so every query must use the existing indexes and a LIMIT, never a full table scan into the browser.
3. A drill-down page for a single record showing its related rows across the other tables listed above, joined the way the existing foreign keys actually define, not a guessed relationship.
4. A CSV export button on the table view, scoped to whatever filters are currently applied, not a silent full-table dump.

CONSTRAINTS
Every query this dashboard runs must be read-only — no INSERT, UPDATE, DELETE, or DDL statement anywhere in the generated code, including in any Edge Function or server action. Do not add authentication to the underlying database itself; auth for who can view this dashboard is handled separately at a separate company SSO gate in front of the whole dashboard URL, outside of Lovable. If a screen I've asked for would require a field or table that isn't in the schema above, stop and tell me exactly what's missing instead of inventing a plausible-looking column name and building against it — a dashboard that silently reads from a column that doesn't exist in production will fail the moment it's pointed at the real database instead of a design-time guess.

REVIEW BEFORE SHIPPING
Before calling this done, list every query the dashboard runs against the production schema in one place, so I can review each one for whether it's genuinely read-only and whether it's going to be slow against real data volume, not just against however much sample data Lovable seeded during the build.