V2: critical startup failures should show actionable errors #35158

Summary

V2 critical startup failures can show only a generic Failed to start server error plus bundled stack frames, without the real cause or an actionable next step.

Evidence

Reported from the V2 TODO LIST thread by James:
https://discord.com/channels/1391832426048651334/1520962938733723720/1522585807997894756

Screenshot showed:

ERROR (#1): Error: Failed to start server
  at ~effect/Utils/internal (/$bunfs/root/chunk-...js:...)
  at ...
  at service.start (...)

The visible output does not show why the server failed to start.

Expected behavior

Critical startup failures should surface a concise user-facing cause and likely fix. Examples:

• port/socket already in use
• invalid config
• database open or migration failure
• permission/path failure
• daemon/server startup failure

Debug stack traces can remain available in verbose/debug mode, but the default failure should not be only /$bunfs/root/... stack frames.

Actual behavior

The CLI reports Failed to start server with bundled stack frames, but no actionable root cause.

Suggested scope

• Preserve/unwrap the underlying startup failure cause when server startup fails.
• Render a short actionable message before any stack trace.
• Avoid showing only bundled /$bunfs/root/... stack frames by default.
• Add smoke coverage for at least one startup failure path if feasible.

Related

• V2: pre-runner errors are not surfaced as assistant message failures #34839 tracks pre-runner errors not being surfaced as assistant message failures; this issue is the CLI/server startup failure path.