Trigger run history and connector sync observability in console

[serge-ivo]

Summary

Expose trigger event history and connector sync results in the console so users can inspect what ran, what was imported, and why something failed.

Why

The backend records agent_trigger_events, but the Settings UI currently only shows trigger definitions and last error. Users need a practical operations view for webhook deliveries, cron runs, manual runs, and connector sync imports/skips/errors.

Scope

• Add a trigger detail/history view or expandable event list in instance Settings.
• Show recent events with status, source type, timestamp, message, and error.
• For sync_connector, show scanned/imported/skipped/error counts.
• Add “Run now” feedback that links to or refreshes history.
• Keep payload display bounded/redacted where needed.

Acceptance Criteria

• A user can open a trigger and see recent received/running/succeeded/failed events.
• Connector sync events show imported/skipped/error counts.
• Failed events display actionable error messages.
• Large payloads are truncated safely in UI.
• E2E covers viewing trigger history after mocked events.
• API/event history remains owner-scoped.

[serge-ivo]

Scope note: this ticket covers observability for triggers. The agent-to-agent connections half has the same gap and is worse — connections have no console UI at all (creating one is a raw API call), and the delivery outbox added in migration 0058 (retry/dead-letter/replay) is API-only. Split out as #182 so the two can land independently.

Also related: #17 is now re-scoped to unify trigger retries onto the same delivery outbox, so the two histories should render from one model rather than two.

[serge-ivo]

Shipped in 2d9ca12.

Verified first — this one was PARTLY STALE. Two of the pieces already existed:

• GET /v1/triggers/:id/events was already implemented and already owner-scoped (WHERE trigger_id = ?1 AND user_id = ?2), so the API half of this ticket needed nothing.
• IndexingTab.tsx already fetched those events — but only for sync_connector triggers, and only to aggregate them into stat boxes on a different tab.

What was genuinely missing is what the ticket's title says: a per-trigger view in instance Settings, and any view at all for the other six actions (create_task, add_knowledge, log_event, run_pipeline, insert_record, run_browse). The Settings card showed only lastError, which answers "is it broken right now" and nothing else.

Shipped

• Each trigger row expands to its recent runs: source (Webhook / Schedule / Run now), status pill, timestamp, headline, and the error.
• sync_connector runs show imported / skipped / scanned plus the per-file error list.
• Payloads stay collapsed behind a "payload" toggle and are pretty-printed and truncated (a webhook body is attacker-influenced and up to 16KB, so an unbounded dump would let one noisy webhook make the whole history unreadable).
• "Run now" opens the history and refetches it, instead of leaving a toast with nowhere to look — and it does that on failure too.
• A health line per trigger derived from history, which calls out "Never run" as its own state: a webhook nobody has ever POSTed to and a working webhook look identical in a list of definitions, and they are very different problems. A succeeded sync that hit per-file errors reads as a warning, not a success.
• Pure rules in store/console/src/lib/triggerEvents.ts (tone, headline, sync counts, truncation, tally, health), 20 unit tests + 1 e2e.

Deliberately not done

• No redaction of payload fields beyond truncation — the viewer is already the owner, and the events endpoint is owner-scoped. If secrets-in-webhook-payloads becomes a concern it wants a real redaction pass, not a UI patch.
• No filtering/pagination of history (capped at the 20 most recent per trigger).
• IndexingTab's aggregate sync view was left as it is — it answers a different question (what is indexed) and still works.

The Triggers card also moved out of SettingsTab.tsx into its own TriggersSection.tsx, following the TeamworkSection precedent.