barista errors: pull recorded errors, triage them, file tagged tickets, and send agents to fix them

Part of #801. Arnel, 14 September 2026: when a café has errors recorded, the expert tells the barista "fetch all issues, analyze them, create tickets and tag them, then run several agents to fix each one."

## What gets fetched

Everything barakoCMS already records, read through the API with a scoped key:
- client errors from sites and consoles (Diagnostics, with their resolution fields from #790)
- failed and dead-lettered workflow runs and messages (#527, #833)
- failed deliveries of webhooks and requests (#671)
- health and service checks that are not Healthy

## Commands

- `barista errors pull --since 7d --json`: grouped by fingerprint (type, message template, top frames, route), with counts, first and last seen, tenants and releases affected.
- `barista errors triage`: for each group, a short analysis (likely cause, the recipe, workflow, block or service involved, and whether it is configuration, a client's own code, or a barako product bug), a severity, and suggested labels.
- `barista errors ticket --tracker github|jira|azure-devops`: one ticket per group, deduplicated against tickets already linked, tagged with severity, area and tenant, and the ticket link written back to the error group's resolution reference (#790), so barakoBrew's errors screen shows it.
- `barista errors fix --parallel 3`: for groups marked fixable, one agent per ticket in its own branch or worktree of the repository that owns the fix (a site kit, a plugin, a service, or a barako product), each opening a pull request that references the ticket and proves the fix with a test that failed before it. Merging stays a person's decision.

## Rules

- **Redact before anything leaves the café.** Personal data, tokens and Sensitive field values are stripped from stack traces, request bodies and messages before an agent or a tracker sees them; the raw record stays in the café.
- **Configuration fixes are plans, not writes.** A fix that is a workflow or recipe change is produced as files and a `barista plan` diff, applied only on the expert's approval.
- **Product bugs go upstream.** An error traced to barakoCMS, barakoBrew, barakoPress or BaryoVM is filed on that repository with the redacted evidence, not patched locally.
- **Bounded.** A cap on tickets per run and agents at once, so one noisy release does not open two hundred tickets.

## Done when

- On a café with seeded errors of three kinds, `pull`, `triage` and `ticket` create one deduplicated, tagged ticket per group with the link written back, running `ticket` again creates nothing new, and no Sensitive value appears in any ticket.

Start by reviewing the existing Diagnostics error records and the resolution reference from #790, then trace how the API exposes failed workflows, deliveries, and health checks. Use the stated pull, triage, and ticket commands as the entry points. Done means the seeded three-kind error scenario creates deduplicated, tagged tickets, writes links back, remains idempotent, and redacts Sensitive values.

Written by the indexing model from the issue text.