geo-multi-tag-narratives

GEO narrative analysis and published reports need to work per tag.

From the weekly sync: we don't want to "rerun the narrative analysis for every
single subcombination" of tags. Each tag gets its own narrative analysis, a
client report shows every tag's analysis as "a drill down if we're to go into a
tag", and picking several tags is just their analyses side by side.

What we need:

1. **One call for every tag's analysis.** Add `POST /api/geo/narratives/batch`.
   It takes the same scope as a narratives run (`prompt_set_id`, optional
   `prompt_set_ids`, `query`, optional `run_started_from` / `run_started_to`)
   plus a list of `tags`, and answers with each tag's cached narrative
   analysis, or none when that tag has no analysis yet in that scope. A tag's
   analysis is the one a narratives run filtered to just that tag would produce
   or reuse: the same responses, the same down-sample, the same cache entry.
   The batch only looks analyses up and never starts one, and it should read
   the scope's responses once for the whole batch rather than once per tag.
   The web app's GEO API schema already has its response shape.

2. **Cited URLs behind each domain.** Every domain in an analysis's citation
   map should also list the specific URLs cited under it, each with the
   responses that cite it. Store them with the analysis, so they come back
   however the analysis is read afterwards.

3. **Per-tag reports.** A published report snapshots one analysis per tag
   instead of a single narrative list; the web app's reports schema already
   has the new snapshot shape. The reports list's narrative count should count
   the narratives of every tag, and a report's page should render the new
   snapshots. Reports published in the old shape don't need to keep working.

The analysis page should use the batch to show each tag's analysis, and only
let someone publish once every tag has one.

## Environment

PostgreSQL on localhost:5432 and the local database endpoint the app's
driver uses are running when you start, and the dev env files point at the
dev database.