Add grouped error issues and frequency analytics

[VibeSWE]

Description

The Errors page previously offered only individual OTLP error spans. It now groups trace and log errors into issues by exact service, error type and message, with full-range counts, frequency charts, sortable pagination and occurrence inspection. The existing error-span view and trace links remain available; log issues open matching stored records in the SQL editor.

Analytics uses the existing SQL API with precise time predicates and safely quoted keys. Trace event expansion and exporter retries count each span once, and exception type/message pairs come from one representative row. Log classification supports textual severity aliases, OTLP numeric severity and Pino/Bunyan levels. Permission failures and unsupported schemas remain distinct. Sample mode supports the same investigation flow.

Validation:

• Production build, TypeScript, formatting and all 2,193 frontend unit tests pass.
• 27 focused Errors unit tests and nine real-server tests pass, covering coherent exception pairs, retries, severity codes, null/escaped keys, pagination, exact time bounds and SQL investigation.
• 12 application browser tests and 12 Errors Storybook checks pass, including accessibility, keyboard focus restoration and a narrow dark viewport.
• Final independent Opus review found no required fixes.

Readable regression tests and the counting/test runbook are included in frontend/docs/error-analytics.md; dated evidence is in frontend/docs/validation-review.md and the Mayfly implementation record.

Grouping is exact; persisted assignment/resolution, fuzzy grouping and cross-dataset correlation remain outside scope. Large-production-dataset query performance and cross-browser behavior have not been established. The full unrelated browser/screenshot suites were not rerun.

This PR has:

• been tested to ensure log ingestion and log query works.
• added comments explaining the intent where it would not be obvious to an unfamiliar reader.
• added documentation for new or modified features and behaviors.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[comment-clanker]

Reviewed commit 91304d506b0b97d285100ae0be87b0600f784e03 with two GPT-6.1-Sol reviewers and an independent Claude Opus 5.5 review. One actionable finding, verified against the ingestion code, is below.

Validation: 27 focused analytics unit tests, 12 Errors/operations browser tests, and TypeScript checking passed. Browser tests used this PR's isolated checkout and a separate server port. The nine opt-in live-server tests were skipped because no reference server was configured; Storybook was not rerun.

[comment-clanker]

[P2] Exclude body-inferred categories from severity-based error classification. p_log_category is not always an explicit severity: when an OTLP record has severity_number: 0, flatten_log_record falls back to a case-insensitive substring search of its body (src/otel/logs.rs:163–173). For example, a body of "0 errors found" produces p_log_category: "ERROR" while its actual severity remains unspecified. Including that category here makes severityPredicate accept the record, inflating the summary, frequency chart and issue counts and including it in SQL investigation results. This also contradicts the documented guarantee that message text is not used to classify errors.

For OTLP logs, use the explicit severity fields, or gate this derived category so the body-search fallback cannot qualify a record. Add a regression fixture with severityNumber: 0 and a non-error body containing "error"; the current live OTLP fixtures exercise specified severities only. This finding is verified from the producer and generated predicate, not a live-server reproduction.