Improve terminal lifecycle logging and actionable error messages without routine shutdown noise

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues.

Related: #20645 covers a specific SQL Server REPL failure and missing launch/exit diagnostics. This issue is a broader review of terminal logging, error classification, and user-facing messages across the terminal lifecycle.

Describe the bug

Review the terminal diagnostics so that real failures are actionable, while typical usage does not produce verbose or alarming error logs. This includes terminals finishing, terminal tabs/windows closing, page navigation/refresh, and AppHost shutdown.

A reported log contains Terminal view failed with a JSON parsing exception in Hex1b's HMP peer-leave handling, surfaced through disposal. The stack is useful because it identifies the protocol operation and teardown path, but it does not explain the initiating action, why the payload is invalid, or whether the failure affected the workload, the viewer, or cleanup.

Do not assume this exception is benign just because it surfaces during disposal. An invalid peer-leave payload may require a protocol or lifecycle fix; improving logging must not hide genuine failures.

Expected Behavior

• Normal workload completion, explicit tab/window closure, navigation/refresh, and expected shutdown cancellation should not produce Warning/Error stack traces. Keep routine lifecycle reporting concise, using Debug/Trace where appropriate.
• Distinguish a finished terminal from a failed launch, failed attachment, lost connection, and unexpected protocol/rendering/cleanup failure. User-facing messages should explain what happened and any useful next action rather than exposing only a generic disconnected-view error.
• Unexpected failures remain visible at an appropriate severity, with the useful exception and enough bounded context to investigate.
• Correlate diagnostics with terminal/session ID, viewer/request ID, source resource or launch title, lifecycle stage, and relevant transport close reason or process exit status when available.
• Avoid repeated reports/log storms for the same failure, including exceptions surfacing again during teardown. Determine whether apparent duplicates come from multiple emissions or multiple output sinks before changing logging.
• Do not log credentials, environment-variable values, terminal input/output, or full protocol payloads by default. Prefer structural protocol context such as message type, negotiated version, and payload length when useful. Keep verbose diagnostics opt-in.

Steps To Reproduce

Reported while using the Terminals playground on Windows and testing #20255. The exact action that triggered this particular peer-leave exception has not yet been established.

For the investigation, exercise normal workload exit, non-zero exit/launch failure, closing a tab, closing a detached terminal window, hiding/reopening the dock, browser navigation/refresh, and AppHost shutdown. Also verify that unexpected transport/protocol failures still produce actionable diagnostics.

Do not treat this list as a confirmed reproduction sequence for the exception below.

Exceptions (if any)

The supplied output reports the following exception twice for the same connection ID. This may reflect multiple logging/output sinks; duplicate emission has not been confirmed. The excerpt is shown once below, with local paths omitted:

fail: Aspire.Hosting.Dashboard.Terminal.TerminalWebSocketProxy[0]
      Terminal view failed (0HNOVEV915OGI:0000025D).

System.Text.Json.JsonException: '0x06' is an invalid start of a value.
Path: $ | LineNumber: 0 | BytePositionInLine: 0.
 ---> System.Text.Json.JsonReaderException: '0x06' is an invalid start of a value.
LineNumber: 0 | BytePositionInLine: 0.

at Hex1b.Hmp1Protocol.ParsePeerLeave(...) (Hmp1Protocol.cs:312)
at Hex1b.Hmp1WorkloadAdapter.HandlePeerLeaveAsync(...) (Hmp1WorkloadAdapter.cs:776)
at Hex1b.Hmp1WorkloadAdapter.ReadPumpAsync(...) (Hmp1WorkloadAdapter.cs:695)
at Hex1b.Hmp1WorkloadAdapter.ReadPumpAsync(...) (Hmp1WorkloadAdapter.cs:727)
at Hex1b.Hmp1WorkloadAdapter.DisposeAsync() (Hmp1WorkloadAdapter.cs:819)
at Hex1b.Hex1bTerminal.DisposeAsync() (Hex1bTerminal.cs:7527)
at Aspire.Dashboard.Terminal.TerminalWebSocketProxy.BridgeAsync(...) (TerminalWebSocketProxy.cs:329)
at Aspire.Dashboard.Terminal.TerminalWebSocketProxy.HandleConnectionAsync(...) (TerminalWebSocketProxy.cs:286)

This establishes that the peer-leave payload could not be parsed as JSON. It does not establish the root cause or a relationship to the SQL Server REPL failure in #20645.

Aspire doctor output

Not collected for this logging/error-message review.

Anything else?

• Environment: Windows, Terminals playground, VS Code/integrated browser.
• Related PR: Upgrade Hex1b and improve dashboard terminal navigation and metadata #20255, head d333d52ceceb7acc94ed506f45991126581f9870 when reported.
• The current checkout pins Hex1b 0.171.0; the runtime version in the supplied log was not independently checked.
• The proxy already distinguishes several cancellation/transport/protocol failures inside its pump. Review the broader lifetime, including disposal, so failures surfaced during teardown are classified and reported consistently without blanket suppression.
• SQL Server REPL reports "Terminal view is not connected" without useful failure diagnostics #20645 also documents a gap where workload completion does not log an exit code, and browser connection warnings do not identify the terminal/view.

Suggested validation

Cover severity/classification and user-facing state for normal completion, expected cancellation/closure, startup/attachment failure, and unexpected protocol/teardown failure. Confirm that routine operations stay quiet at the default logging level and that genuine failures retain useful correlation and diagnostic details.