feat(webapp,run-store): route run-graph reads and writes through the run-store router (#4237)

## Summary

Run-graph data (runs, batches, waitpoints, and their related tables) can
now live in a database separate from the control plane, with every read
and write routed to the correct database by each run's residency. This
makes reading and writing run data more reliable once the two are split,
and is a no-op for single-database installs.

## Design

- Run-graph table access goes through the run-store router, which
selects the legacy or the new run-ops store per run instead of assuming
one shared client.
- The legacy run-ops client is now independently pointable, so legacy
run data can be served from its own database (and replica) rather than
the control-plane connection.
- Run-graph writes go straight to the run-graph database instead of
being forwarded through the control plane, and replication targets are
split so runs in the new database still replicate to analytics without
under-counting.
- Read-through slots refuse the control-plane client, so a missing
residency fails loudly instead of silently reading the wrong database.
- Migration `20260710120000_drop_remaining_run_graph_seam_foreign_keys`
drops the foreign keys that still crossed the run-graph / control-plane
seam, which is what lets the two live in separate databases.

The split stays off unless explicitly enabled and the two databases are
confirmed physically distinct; startup fails closed otherwise.

Verified by running the full dashboard end-to-end suite against both a
single-database configuration and a three-database configuration
(control plane, the new database, and a physically separate legacy
database), with runs on both residencies. No misrouted reads in either
configuration.

docker/scripts/entrypoint.sh

@@ -27,6 +27,22 @@ else
   echo "RUN_OPS_DATABASE_URL not set, skipping run-ops migrations."
 fi
 
+# Run-ops split: keep the legacy runs DB's schema current by applying the full @trigger.dev/database
+# migrations to it too, pointed at its direct (non-pooled) URL. Only runs when that URL is configured;
+# installs that never set it skip this entirely.
+if [ -n "$RUN_OPS_LEGACY_DIRECT_URL" ]; then
+  if [ "$SKIP_RUN_OPS_LEGACY_MIGRATIONS" != "1" ]; then
+    echo "Running legacy run-ops migrations"
+    # Subshell with tracing off so `set -x` does not print the DSN (with credentials) to the logs.
+    (set +x; DATABASE_URL="$RUN_OPS_LEGACY_DIRECT_URL" DIRECT_URL="$RUN_OPS_LEGACY_DIRECT_URL" pnpm --filter @trigger.dev/database db:migrate:deploy)
+    echo "Legacy run-ops migrations done"
+  else
+    echo "SKIP_RUN_OPS_LEGACY_MIGRATIONS=1, skipping legacy run-ops migrations."
+  fi
+else
+  echo "RUN_OPS_LEGACY_DIRECT_URL not set, skipping legacy run-ops migrations."
+fi
+
 if [ "$SKIP_DASHBOARD_AGENT_MIGRATIONS" != "1" ]; then
   echo "Running dashboard agent migrations"
   pnpm --filter @internal/dashboard-agent-db db:migrate:deploy