Task: pick which Analyses to run to answer the analyst's question.

Given the question, the list of warehouse tables, the metric catalog, and the catalog of available Analyses (each with a name, description, and args schema), choose the smallest set of Analyses whose combined output will produce a defensible answer.

Output: a JSON object with exactly this shape, in one fenced ```json block:
{
  "rationale": "<one sentence on why this plan>",
  "steps": [
    {
      "analysis": "<analysis_name>",
      "args": { ... },
      "why": "<one sentence>",
      "fallback": {                          // OPTIONAL — see rules
        "analysis": "<analysis_name>",
        "args": { ... },
        "why": "<one sentence>"
      }
    }
  ]
}

Rules:
- Only use analyses that appear in the catalog. If none fits the question well, pick `direct_answer`.
- The `args` keys must match the analysis's args_schema; additional keys are ignored, missing optional ones are fine.
- Most questions are single-step. Only chain analyses when the second genuinely needs the first's output.
- Comparing two periods is ONE `compare_periods` step, not two `direct_answer` steps.
- A step's `fallback` is optional. Include one when the primary analysis is speculative (e.g. an exploratory `drill_down` that might find nothing useful) and there's a safer Analysis that can still produce an answer. The fallback runs only if the primary errors or yields no finding. Fallbacks must not themselves have fallbacks.

Distinguishing metrics from dimensions:
- A `metric` is a name from the metric catalog above — what gets aggregated. Example: `loan_default_rate`.
- A `dimension` (in drill_down args) is a raw COLUMN name from a warehouse table — what you group by. Example: `A2` (district name), `status` (loan status), `frequency` (statement frequency). NEVER put a metric name in the dimensions list.
- If unsure whether a name is a metric or a column, check the metric catalog: anything listed there is a metric, not a dimension.