Surface non-blocking agent startup script failures to the user

Problem

When an agent ends up in start_error or start_timeout, the extension continues the connection and only writes a line to the Coder output channel:

https://github.com/coder/vscode-coder/blob/96dd90864e515d1f4e82fa6a7fd951e764c72f1e/src/remote/workspaceStateMachine.ts#L240-L245

Non-blocking startup scripts are useful because a developer can still reach a terminal and repair the workspace when one fails. But a failed script usually means the workspace is unhealthy, and right now someone connecting through the extension gets no visible signal. Output channel messages are easy to miss.

Raised in #1113 (comment). Tracking separately because the fix does not depend on the panel redesign.

Current behaviour

src/remote/workspaceStateMachine.ts treats both states the same way: close the agent log stream, log at info level, return true to continue connecting.

• start_error logs "Agent startup scripts failed, but continuing"
• start_timeout logs "Agent startup scripts timed out, but continuing"

Suggested ways to surface it

Roughly in order of effort:

1. Warning notification on connect. Show vscode.window.showWarningMessage when the agent reaches start_error or start_timeout. Include the agent name, and the failing script if we can identify it. Offer actions:
   • "View Logs" to run the existing coder.viewLogs command
   • "Show Startup Logs" to reveal the agent log terminal already populated by streamAgentLogs
   • "Dismiss"
2. Write a banner to the connection terminal. The state machine already writes to a terminal during startup. A clear failure banner there survives in scrollback, so the user can find it after the fact.
3. Persistent status bar warning. A notification can be missed if the window is unfocused during connect. A warning status bar item that stays until clicked gives the user something to come back to. WorkspaceMonitor already owns a status bar item and is a reasonable home for this.
4. Decorate the tree item. Longer term, an unhealthy indicator on the workspace or agent in the Workspaces panel. This is the part that overlaps with #1113, so it can follow that work.

Suggest starting with 1 and 2, then evaluating 3.

Open questions

• Should this respect coder.disableNotifications? That setting is documented as covering notifications delivered by the Coder deployment, so a client side health warning may deserve its own setting, for example coder.disableStartupScriptWarnings.
• Should start_timeout read differently from start_error? A timed out script may still be running and eventually succeed, so the wording should not claim it failed outright.
• Can we name the specific script that failed? Worth checking whether the agent scripts payload exposes per script exit status. If not, the message stays generic and points at the logs.

Acceptance criteria

• Connecting to a workspace whose non-blocking startup script failed produces a visible warning, not just an output channel line.
• The warning gives a direct path to the relevant logs.
• The connection still succeeds, matching today's behaviour.
• Both start_error and start_timeout are covered, with wording appropriate to each.

Created on behalf of @EhabY