Audit Hex1b `IHex1bTerminalWorkloadAdapter.ReadOutputAsync` end-state semantics in `DcpUpstreamAdapter`

From PR #17866 review feedback (Mitch's Round 6, item #20).

`DcpUpstreamAdapter.ReadOutputAsync` (in `src/Aspire.TerminalHost/DcpUpstreamAdapter.cs`) currently collapses five distinct end-states into `ReadOnlyMemory.Empty`:

1. Already-disposed
2. Connect failure
3. `WaitToReadAsync` returning false (channel completed = EOF)
4. `TryRead` race miss
5. `ChannelClosedException`

This is suspect because Hex1b's `IHex1bTerminalWorkloadAdapter` contract for `Empty` is currently undocumented from this repo:

- If `Empty` means "EOF / shut down the workload", case (4) will cause Hex1b to tear down the workload spuriously on a benign race after wakeup with no successful `TryRead`.
- If `Empty` means "spurious, call again", cases (2)/(3)/(5) will turn into a tight busy-loop.

Need to:

1. Confirm the `IHex1bTerminalWorkloadAdapter.ReadOutputAsync` contract with Hex1b (post-disposal expectations, EOF sentinel, spurious-wake handling).
2. For case (4): loop on `TryRead` until success or fall back to `WaitToReadAsync`.
3. For cases (2)/(3)/(5): ensure the return value matches Hex1b's "workload terminated" sentinel - probably throw or return a distinct sentinel rather than `Empty`.

Original review comment: https://github.com/microsoft/aspire/pull/17866#discussion_r... (review thread ID `PRRT_kwDOKYQzfc6Gq5xk`).

Parked from the WithTerminal PR because the fix shape depends on the Hex1b contract clarification.