[Feature]: Expose resolved default time dimension per metric in MCP metadata

### Is your feature request related to a problem?

MCP clients that do introspection ("for this metric, what concrete time dimension does `metric_time` resolve to?") cannot answer the question from current MCP metadata.

Concrete trigger we hit:

1. User asks an agent for a ratio metric grouped by `metric_time`.
2. The MCP server correctly resolves `metric_time` at query time — the compiled SQL shows `DATE_TRUNC('day', flight_date) AS metric_time__day`.
3. User follow-up: *"which date did you group by?"*.
4. The agent can see the literal `group_by: [{name: "metric_time"}]` it passed, but no MCP tool tells it what that abstract default resolved to for this specific metric:
- `get_metric_metadata` returns metric info but omits `defaults.agg_time_dimension` (and for ratio/derived metrics, the resolution depends on the underlying measures, which may each override the parent semantic model's default).
- `get_dimensions` returns generic `metric_time` with granularities, no per-metric resolution.
- `get_semantic_model_details` returns measures but without their `agg_time_dimension` override.
- `list_metrics` lists dimension names side by side, no indication of which `metric_time` maps to.
5. The only workaround is to call `get_metrics_compiled_sql` and parse `AS metric_time__` out of the SQL text — fragile, and not what an MCP source-of-truth server should force clients to do.

### Describe the solution you'd like

Surface the resolved default time dimension on metric metadata.

Concretely, extend the `get_metric_metadata` (or `list_metrics`) response with a field like `default_time_dimension` that names the semantic dimension `metric_time` resolves to for the metric in question. For derived and ratio metrics, resolve through the underlying measure chain and return the effective value — either a single resolved dimension, or an ordered list when numerator and denominator differ.

Example (schematic):

```json
{
"name": "some_ratio_metric",
"type": "RATIO",
"default_time_dimension": {
"name": "",
"source": "measure_override",
"resolved_via": [".agg_time_dimension"]
}
}
```

The client should be able to answer *"what does `metric_time` mean for this metric?"* with one call, without parsing compiled SQL.

### Describe alternatives you've considered

- **Parse compiled SQL from `get_metrics_compiled_sql`.** What we do today. Works, but is fragile (depends on the exact `DATE_TRUNC('', ) AS metric_time__` shape) and wastes a round trip for a metadata question.
- **Parse semantic-model YAML client-side.** Defeats MCP's role as source of truth; requires the client to have filesystem access to the dbt project, which isn't generally the case for remote MCP consumers.
- **Expose raw `agg_time_dimension` per measure in `get_semantic_model_details`.** Lower-level. For ratio/derived metrics the client still has to walk the measure chain and do the resolution itself. Higher-level resolution at the metric layer is simpler for all consumers.

### Additional context

Precedent: #437 (closed COMPLETED) addressed a structurally similar gap — `config.meta` was absent from `get_dimensions` output and got added to the tool's response. This request is the equivalent for "which time dimension does `metric_time` resolve to per metric."

Downstream consumer: an introspection-capable analytics agent that currently has to parse compiled SQL to answer a metadata question.