Batch Analyse requests and survive opaque provider schema budgets

Analyse now classifies up to ten same-kind transactions per provider
request: the registry and history travel once per batch, so a
thousand-row backfill costs about a hundred paced requests instead of a
thousand. The answer schema appears once — an array item carrying an
enum-bound ref — because providers meter strict schemas by token cost:
duplicating registry enums per row, or bounding arrays with
minItems/maxItems that Gemini expands per element, rejects real
registries with a bare HTTP 400. Row count, duplicate refs, duplicate
tags and taxonomy bounds are all enforced server-side instead, and a
request still rejected outright halves until accepted, remembering the
working size for the run. Batch requests scale the HTTP budget by row
count, chunk failures cannot abort a run whose later rows succeeded,
and rows resolved against one snapshot share one minted merchant.

Measured on a real 165-row month over a zero-data-retention route:
165 analysed, 152 proposals, 0 errors, 17 requests, under 8 minutes.

Fresh installs default to google/gemini-3.8-flash, the model that
demonstrably honors strict structured outputs over a ZDR route. Preview
changes now carry counterparty, amount and currency, and the review
list shows the amount with a counterparty fallback for banks that leave
descriptions empty.

internal/classification/candidates.go

@@ -296,7 +296,7 @@ func (c candidateSet) schema() map[string]any {
 			"merchant_id":  map[string]any{"type": []string{"string", "null"}, "enum": merchantEnums},
 			"new_merchant": map[string]any{"type": []string{"string", "null"}, "maxLength": 100},
 			"category_id":  map[string]any{"type": "string", "enum": candidateIDs(c.categories)},
-			"tag_ids":      map[string]any{"type": "array", "maxItems": len(tagIDs), "items": tagItems},
+			"tag_ids":      map[string]any{"type": "array", "items": tagItems},
 			"confidence":   map[string]any{"type": "string", "enum": []string{"high", "medium", "low"}},
 		},
 	}