MCP: dashboard tools can't produce a finished dashboard — no grid layout, no filter wiring, no text cards

## Describe the limitation

The MCP dashboard tools get an agent 90% of the way — `create_question` + `create_dashboard` work well — but the last 10% (making the dashboard presentable and interactive) is impossible through MCP and must be finished by hand in the UI:

1. **No layout control.** `create_dashboard` auto-positions cards; `update_dashboard`'s dashcard mutations only support `add` / `remove` / `move` (top|bottom) plus a coarse `display_size` hint (wide|tall|full). There is no way to set `row` / `col` / `size_x` / `size_y`, which the REST API (`PUT /api/dashboard/:id`) has always supported.
2. **No dashboard parameters.** Filters can't be created or wired to cards via MCP. Combined with native-SQL cards (from `construct_native_query`) having no template-tag support, agent-built dashboards end up entirely non-interactive.
3. **No text/heading cards.** Section headers and explanatory text — half of what makes a dashboard readable — can't be added.

## Real-world context

We built a 9-card monitoring dashboard (4 scalars, 1 trend line, 4 breakdown charts) entirely through MCP in a single agent session. Card creation was smooth: `construct_native_query` → `create_question` (with visualization_settings) → `create_dashboard` with `question_ids`. The result then required manual UI work for layout and section headers, and can never get dashboard filters because the cards are native SQL. For "AI builds the dashboard, humans consume it" workflows this is the main remaining gap.

## Proposal (incremental, in priority order)

1. **Explicit dashcard positions.** Extend the dashcard mutations with an optional position, additive to the existing schema:
```json
{"action": "add", "card_id": 42, "position": {"row": 0, "col": 12, "size_x": 12, "size_y": 6}}
```
plus a corresponding `{"action": "update_position", "dashcard_id": 7, "position": {...}}`.
2. **Text cards.** `{"action": "add_text", "text": "...", "position": {...}}` — the `virtual_card` text dashcards the REST API already supports.
3. **Dashboard parameters.** A minimal version first: create a parameter and map it to MBQL cards' fields. Native-card wiring can come later, since it requires template-tag support in card creation.

Happy to contribute a PR for (1) if the approach sounds acceptable — it looks like a small additive change in the agent-api dashcard mutation handling.

## Related

- #77926 asks for broader parity with mb-cli; this issue is narrower and concrete: the minimum set needed for an agent to hand over a finished dashboard.

## Info

- Metabase version: v0.63.15.4 (self-hosted, Docker)
- MCP client: Claude Code (streamable HTTP, header auth)

Start with the agent-api dashcard mutation handling described in the proposal, then compare its supported mutations with the REST PUT /api/dashboard/:id behavior. Scope the first increment around explicit dashcard positions for add and update_position, and verify that the dashboard can receive and apply row, col, size_x, and size_y values.

Written by the indexing model from the issue text.