===> THIS IS THE DEFAULT, CORRECT TOOL whenever a user asks for "the report",
"research", "the latest research", "analysis", "a writeup", or "the PDF" for a
ticker (e.g. "get me the latest research on SNOW"). It is the FAST path. For a
symbol with a FRESH saved report plan it does not hand back a pre-built PDF: it
pulls the plan itself — the JSON the platform saved when the symbol's latest
material event published (brief, queries, results, format map) — and renders it
straight into the user's template in ~10-20 s. Every other symbol comes back
with its cached PDF. ALWAYS call this before `generate_report_for_stock`, which
is a ~10 min full rebuild.

If the user's intent is an OPEN-ENDED or exploratory QUESTION rather than a request
for this existing report, do NOT use this tool — default to `explore_data_catalogue`
(fast, interactive), and reach for `generate_research_report` only when the user
EXPLICITLY asks for a full deep-dive writeup. A BESPOKE report ("the SNOW report,
but built around product revenue and RPO") is not a rebuild either: explore the
items the user named, ideate with them on the result sets, and lay the agreed
results out in their template (`get_user_template`) with your own document tooling.

Accepts one OR many symbols. Returns
{"result":    [{"symbol": "AAPL", "url": "<presigned pdf url>",
                "report": "<base64 pdf>", "generated_at": "<iso utc>",
                "age_hours": 5.2, "latest_event_at": "<iso>", "stale": true}, ...],
 "missing":   ["XYZ", ...],
 "rendering": {"PLAY": {"task_id": "...", "status": "PENDING", "symbol": "PLAY"}}}
Every symbol lands in exactly ONE of the three. A `result` hit carries BOTH
representations of the same PDF: `url` is a short-lived presigned link (valid
~6h) — hand it to the user to download/open the document directly (and prefer it
on clients that can't handle a large base64 blob); `report` is the inline base64
PDF — decode it to read, render, or summarize the report's contents yourself.
Split a list longer than 100 symbols across calls.

READ ALL THREE BEFORE YOU HAND ANYTHING OVER. Nothing regenerates on its own:
  in `rendering` -> the symbol's saved plan is fresh and is being rendered into the
                    user's template (~10-20 s). Poll get_task_status(task_id); the
                    finished result carries {"pdf": "<base64>", ...} — hand the
                    user THAT. Never call generate_report_for_stock for it: the
                    render already is the fresh report.
  stale: false   -> the cached PDF reflects the symbol's latest report inputs. Serve it.
  stale: true    -> the saved plan itself is out of date (a print, a filing, a 13F
                    refresh landed after it; `latest_event_at` says when), so there
                    is nothing fresh to render. Hand over the stale PDF with that
                    caveat and offer generate_report_for_stock(ticker) — a full
                    rebuild, ~10 min. Start it when the user wants the refreshed
                    report; never fan rebuilds out across a list of names unasked.
  stale: null    -> no report inputs are known for the symbol, so freshness cannot
                    be judged. Serve the PDF and quote `generated_at` / `age_hours`.
  in `missing`   -> no plan to render and no cached PDF. generate_report_for_stock(ticker)
                    builds the first one (~10 min, saved so later calls here render
                    it in seconds) — say so before starting it — or `onboard_symbol`
                    if the ticker is not covered.
To see which symbols have a fresh plan READY to render — by the event that
triggered it, across the universe, before anything is pulled — use
`list_available_reports`: it lists saved plans, not cached PDFs.

Rate-limited to 500/hour. Requires auth (your MCP client attaches the OAuth bearer
automatically).