feat(webapp,run-engine): queue metrics and health dashboard

.changeset/mcp-server-starts-without-wizard.md

@@ -0,0 +1,5 @@
+---
+"trigger.dev": patch
+---
+
+`trigger mcp` now always starts the MCP server, and the interactive install wizard has moved behind `trigger mcp --install`. Previously the wizard opened whenever stdout was a terminal, so any MCP host that spawns the command over a pseudo-terminal waited on a server that never started and eventually timed out.

.changeset/report-health.md

@@ -0,0 +1,12 @@
+---
+"@trigger.dev/core": patch
+"trigger.dev": patch
+---
+
+Ask whether an environment is healthy and get an answer instead of a wall of charts. `trigger report health` returns a verdict on three questions: is work flowing, are the runs that start succeeding, and is the telemetry fresh enough to trust either answer. When something looks wrong it names the most likely cause and a next action.
+
+```bash
+npx trigger.dev@latest report health --env prod --period 24h
+```
+
+The verdict is computed server side, so the CLI, the new `get_report` MCP tool, and `GET /api/v1/reports/health` all return the same text with the same sparklines. In MCP hosts that support prompts, `report` is also available as a slash command.

.server-changes/agent-detail-metrics-layout.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: improvement
+---
+
+The agent detail page now uses the same layout as the other metrics pages: filters stay pinned at the top, the activity charts sit in a row beneath them, and the tabs and table scroll with the page, with the agent config in a resizable panel on the right.

.server-changes/paginate-concurrency-keys-table.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: improvement
+---
+
+A queue's concurrency keys are now paged and searchable, so a queue with thousands of keys shows all of them instead of only the busiest 50.

.server-changes/queue-concurrency-percent-limits.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: feature
+---
+
+A queue's concurrency limit can now be set as a percentage of your environment limit, from the dashboard or the API. Percentage limits track the environment limit, so raising or lowering it re-divides capacity without you editing every queue.

.server-changes/queue-metrics-dashboard.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: feature
+---
+
+See how every queue in an environment is doing: backlog, throughput, concurrency against its limit, when it was throttled, and how long runs waited before starting. Each queue also gets its own page, which breaks the same numbers down per concurrency key so you can tell whether one key is starving the rest.

.server-changes/reject-queue-limit-above-env-limit.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: breaking
+---
+
+Setting a queue concurrency limit higher than your environment limit is now rejected with an error instead of being silently reduced to the environment limit, so a queue never looks like it has more capacity than it can get. Limits already saved are unchanged.