Surface the actual Share Control PDU type when 'unexpected Share Control Pdu' fires

## Problem

When ironrdp receives a Share Control PDU during Capabilities Exchange that isn't `ServerDemandActive`, the user-facing error is:

```
RDP connect finalize failed: Error { context: \"unexpected Share Control Pdu (expected ServerDemandActive)\", kind: General, source: None }
```

The actual PDU type that *was* received isn't included in the error string. From a downstream client's perspective (Haven, in this case) this means we can't distinguish between, e.g.:

- Server sent a `SetErrorInfo` PDU rejecting the session for a specific reason (the most informative case — that PDU has a numeric error code we'd want to surface)
- Server sent `SaveSessionInfo` or `Server Auto-Reconnect Status` instead of demand-active
- Server sent some other implementation-quirk PDU

## Reported via

[GlassHaven/Haven#109](https://github.com/GlassHaven/Haven/issues/109#issuecomment-4328969739) — agevlakh's GNOME Remote Desktop on Fedora 44 hits this after CredSSP succeeds. We were able to characterise everything *up to* this point (TLS ✓, NLA ✓ now after a separate sspi-rs interop session) but the actual server response that ironrdp rejects is opaque.

## Asks

1. Include the received PDU's discriminant (and, ideally for `SetErrorInfo`, the error code value) in the `context` string when raising this error. Even just `unexpected Share Control Pdu (got SetErrorInfo, expected ServerDemandActive)` would let us trace it back to MS-RDPBCGR §2.2.5.1 and explain the failure to users.
2. Optionally a structured variant of `ConnectorErrorKind` for "server rejected at capabilities phase" so downstream code can map to a friendlier message instead of substring-sniffing the `Reason` string.

Happy to PR if you'd like — would be a small change in `crates/ironrdp-connector/src/connection_activation.rs` (or wherever the demand-active wait is checked).