fix(model-fallback): distinguish empty_response / no_error_details / unclassified instead of collapsing to "unknown"

Summary

Currently, three distinct failure scenarios all produce reason: "unknown" in model fallback events. Each has enough information to be labelled more specifically, but the label is discarded before surfacing to the user.

The three collapsed paths (in errors-CJULmF31.js / classifyProviderRuntimeFailureKind)

1. Empty response — no message, no HTTP status

if (!message && typeof status !== "number") return "unknown";

The error object arrived with no body and no status code. This typically means the provider socket closed unexpectedly (Ollama worker OOM, process crash, CUDA error). Suggested reason: "empty_response"

2. Provider explicitly returned no details

if (isExactUnknownNoDetailsError(raw)) return toReasonClassification("unknown");
// isExactUnknownNoDetailsError matches: "unknown error (no error details in response)"

The provider returned a well-formed response, but the error payload was explicitly empty. Different from a socket crash — the request completed, just with no useful error. Suggested reason: "no_error_details"

3. Catchall — fell through all classifiers

return "unknown"; // end of classifyProviderRuntimeFailureKind

The error message didn't match any known pattern (rate_limit, timeout, overload, billing, auth, context overflow, DNS, etc.). The raw message exists but no classifier claimed it. Suggested reason: "unclassified"

Why this matters

• Debugging: reason: unknown gives no actionable signal. reason: empty_response immediately points to a local model crash or network drop. reason: unclassified tells you to look at errorPreview for the raw text.
• Retry logic: shouldAllowCooldownProbeForReason and shouldUseTransientCooldownProbeSlot already treat "unknown" as transient — splitting it lets each sub-type get the right cooldown policy independently.
• Observability: errorPreview is sometimes empty when reason is unknown (especially for empty_response). Users see a fallback notice with no reason and no preview — zero debug signal.

Suggested fix

// Path 1: no message, no status
if (!message && typeof status !== "number") return "empty_response";

// Path 2: explicit no-details response  
if (isExactUnknownNoDetailsError(raw)) return toReasonClassification("no_error_details");

// Path 3: catchall — at minimum preserve the raw error in errorPreview
return "unclassified";

For path 3, even if the reason label stays "unknown", ensuring errorPreview is always populated with the raw message would be a meaningful improvement on its own.

Affected surfaces

• Model fallback notice shown to users: ⚠️ Model Fallback: X (selected Y; unknown)
• cron runs output: "reason": "unknown"
• Gateway log: model_fallback_decision events with reason: "unknown"
• Cooldown probe logic in shouldAllowCooldownProbeForReason / shouldUseTransientCooldownProbeSlot

Notes

• "unknown" is currently in TRANSIENT_FALLBACK_REASONS — the three new labels should inherit the same transient treatment unless there's a reason to differentiate
• This came up debugging Ollama (granite4:3b-h) worker crashes where the socket closes with no body — currently indistinguishable from a malformed provider response or a genuine catchall