Observe failed packet bus completions without losing waiter errors

[YAJeff]

Queued packets often have no completion waiter. When a transport write fails, the server catches the error and calls MqttPacketBusItem.Fail, but the item's faulted completion task can later raise UnobservedTaskException during collection.

Have the packet-bus item observe its own completion fault after recording it. The task remains faulted: existing and late WaitAsync callers still receive the original exception. Public signatures, successful completion, cancellation, and first-completion behavior are unchanged. No global exception suppression is added.

The regression includes an unobserved raw-task positive control and verifies that the failed packet task is actually collected. Additional cases verify existing/late waiter exception identity and failure after success/cancellation.

Validation:

• The new regression fails against unmodified master 18731d9f and the current Enforce per-connection MQTT 5 server send quota #2265 head, while the other packet-bus-item cases pass.
• Windows .NET 8 and .NET 10: all 57 selected internal, low-level-client and concurrent-publish tests pass on this change.
• Linux .NET 10.0.12: 55 selected tests pass in a network-disabled container. The two external-network tests fail there, then both pass when rerun with networking enabled. Original failure logs are retained; this was not one uninterrupted green run.
• A separate baseline-compiled probe runs unchanged on Windows/Linux .NET 8/10. Both direct failures and controlled failures in the real server send loop reproduce eight unobserved completions before the change and zero afterward. Existing/late waiter, completion and cancellation controls pass. The same patch also passes these probes when applied locally to Enforce per-connection MQTT 5 server send quota #2265's head.
• Release builds and git diff --check pass.

This is a standalone fix for a pre-existing ownership gap. It was investigated after the cleanup exceptions in #2265/#2266, but the historical CI logs do not identify their originating packet or test; this PR does not claim those historical triggers have been identified.