fix(mcp): align Jinja context across query preview and compile paths

### Summary

Follow up on #42822 by applying the shared MCP Jinja form-data context helper to sibling programmatic query paths that compile, preview, or execute `ChartDataCommand`.

The review on #42822 identified that a chart can resolve request-dependent Jinja inputs during `get_chart_data` while sibling tools such as `get_chart_sql` may still render fallback values (for example, `No filter`). This can make displayed/previewed SQL diverge from executed SQL.

### Candidate paths

Audit and, where applicable, cover:

- `get_chart_data._query_from_form_data` (`form_data_key` branch)
- `get_chart_sql`
- `get_chart_preview`
- chart `preview_utils`
- chart `compile`
- `semantic_layer/get_table`
- any other programmatic `ChartDataCommand` construction paths

### Acceptance criteria

- Equivalent query contexts expose the same Jinja inputs across execution, SQL generation, compilation, and preview paths.
- `filters`, `time_range`, `url_params`, and implicit dataset lookup behave consistently where supported.
- Tests use real `QueryObject`/`QueryContext` shapes rather than mocked serializer output.
- Authorization and guest-scope behavior remain unchanged.
- Each adopted path has focused regression coverage.

### Context

Raised during review of #42822: https://github.com/apache/superset/pull/42822#discussion_r3784861047

Start by auditing get_chart_data._query_from_form_data, get_chart_sql, get_chart_preview, chart preview_utils, chart compile, and semantic_layer/get_table for programmatic ChartDataCommand construction. Compare real QueryObject/QueryContext shapes across these paths, then add focused regression coverage so filters, time_range, url_params, implicit dataset lookup, authorization, and guest scope behave consistently.

Written by the indexing model from the issue text.