`sql_analyze` is the #1 tool failure — 10,266 failures in 7 days, 80% are "unknown error"

[anandgupta42]

Problem

sql_analyze is the most failing tool in the CLI by a significant margin — 10,266 failures in the last 7 days, nearly double the next highest (edit at 4,370).

Breakdown

There are two distinct issues here:

1. "unknown error" — 8,302 occurrences (80%)

Same pattern as altimate_core_validate — the actual error is swallowed and replaced with a generic "unknown error". No error class, no actionable information.

This is likely the same root cause as #451 — error propagation from the core bridge is not surfacing the real error message.

2. Lint/analysis findings logged as "failures" — 1,964 occurrences (20%)

The remaining 20% are not actually failures — they are valid analysis results being classified as core_failure events:

Occurrences	Finding
818	SELECT without LIMIT may return excessive rows
822	SELECT * usage warnings
153	SELECT * usage (single issue)
83	Jinja template expression in SQL (safety)
30	Aggregation before JOIN

These are the expected output of sql_analyze — the tool found issues in the SQL. They should be logged as successful tool calls with findings, not as core_failure events.

Impact

• Inflates the overall failure rate (~50% of all core_failure events are from this one tool)
• Masks real failures behind the "unknown error" wall
• Makes it impossible to distinguish between "tool crashed" and "tool found a lint issue"

Suggested fix

1. Separate concerns: sql_analyze findings (lint warnings, safety issues) should be returned as successful results, not errors
2. Surface real errors: Apply the same error propagation fix as altimate_core_validate returns "unknown error" with no actionable details (1,200+ failures) #451 to expose actual crash details
3. Add error classification: Use error_class properly — "lint_finding" vs "crash" vs "timeout" etc.