Prevent raw internal errors from appearing in user-facing Observability

[charlesrhoward]

Problem

User-facing Observability renders persisted job errors verbatim. This exposes implementation and infrastructure details that users cannot act on and may disclose sensitive configuration names, internal routes, provider details, or stack information.

Concrete incident on 2026-08-04: Trigger-based runs displayed:

INTERNAL_API_SECRET is required for delegated internal API calls

This was a Mogplex runtime configuration failure, not a user error. The underlying failure should remain available to operators, but a user should see a safe message such as:

Mogplex could not start the workspace for this run. Retry the run, or contact support if it continues.

Current direct rendering path:

• lib/workflows/automation-job-workflow.ts persists the raw caught error to job_runs.error.
• app/(dashboard)/[scope]/observability/_components/job-expanded-row.tsx renders job.error verbatim as the Run Error.

Expected behavior

Introduce a centralized error-presentation boundary for user-facing workflow and Observability surfaces:

• Preserve full raw errors in internal diagnostics such as server logs, Sentry, and Trigger.dev metadata.
• Return/render a sanitized display error to users.
• Keep genuinely user-actionable failures specific, such as missing model selection, invalid flow configuration, repository authorization, or quota limits.
• Map platform configuration, machine-auth, provider-internal, database, stack-trace, and unknown failures to safe product language with a stable error or correlation ID.
• Never expose secret names, secret values, internal hostnames/routes, stack traces, SQL/provider internals, or raw exception envelopes.
• Apply sanitization to existing persisted errors at the API/presentation boundary so old records are safe without requiring a data migration.

Acceptance criteria

• A shared classifier/presenter distinguishes user-actionable failures from internal failures; this is not a one-off check for INTERNAL_API_SECRET.
• User-facing Observability never renders raw internal job_runs.error, node-run errors, AI-call errors, or tool errors without classification.
• The exact incident message above is replaced with a generic safe message.
• Raw diagnostic detail remains available to authorized operators outside user-facing payloads.
• API responses backing user-facing Observability do not leak the raw internal error in an alternate field.
• Regression tests cover environment-variable names, stack traces, internal URLs, database/provider errors, and known actionable errors that should remain specific.
• The UI provides a stable incident/correlation identifier when an internal error occurs.

Security note

This is primarily a trust and UX defect, but the allowlist should be conservative because raw exception text can become an information-disclosure issue as integrations and providers add more detailed errors.