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

[gonzalorhervas]

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__<grain> 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):

{
  "name": "some_ratio_metric",
  "type": "RATIO",
  "default_time_dimension": {
    "name": "<dim_name>",
    "source": "measure_override",
    "resolved_via": ["<measure_name>.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('<grain>', <EXPR>) AS metric_time__<grain> 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.