fix(connector): surface actual PDU type when an unexpected Share Control PDU arrives

[GlassOnTin]

Closes part of #1232.

Why

Three error sites in the connector previously printed only the expected PDU type, dropping the actual type the server sent on the floor. That made interop bugs harder to diagnose than necessary.

Concrete case from #1232 (originally surfaced via Haven#109 on a GNOME Remote Desktop server): when a client connects to GRD without advertising EGFX, GRD's `freerdp_peer::Capabilities()` callback fails — confirmed via journalctl on the server:

```
gnome-remote-desktop-daemon: [RDP] Client did not advertise support for the Graphics Pipeline, closing connection
[ERROR] [rdp_peer_handle_state_demand_active]:
[CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE] freerdp_peer::Capabilities() callback failed
```

GRD then sends a Server Deactivate All PDU instead of Server Demand Active. The connector saw `ServerDeactivateAll`, didn't match `ServerDemandActive`, and reported "unexpected Share Control Pdu (expected ServerDemandActive)" — with no hint that the server had sent Deactivate All (which itself is a strong signal the server gave up during caps validation, e.g. because of a missing capability).

What

Replaces three `general_err!` sites in the connector with `reason_err!` calls that include `pdu.as_short_name()` (the helper already exists on `ShareControlPdu`):

File	Function	Diagnosis context
`connection_activation.rs:125`	`ConnectionActivation::CapabilitiesExchange`	server's reply to `ConfirmActive`
`legacy.rs:152`	`decode_share_data`	wraps `decode_share_control` for callers expecting Data
`legacy.rs:213`	`decode_io_channel`	I/O channel dispatcher for the session loop

Now diagnoses look like:

unexpected Share Control PDU during capabilities exchange: got Server Deactivate All PDU (expected Server Demand Active PDU)

vs. the previous:

unexpected Share Control Pdu (expected ServerDemandActive)

which immediately points at GRD-style "I rejected your caps and deactivated the share" rather than leaving callers to guess from network traces.

Scope

• No behavior change beyond the error string.
• Existing matches on `ServerDemandActive` / `Data` / `ServerDeactivateAll` continue to dispatch the same way.
• The wider EGFX-as-client work (so IronRDP-based clients can actually interop with GRD instead of just diagnosing the failure better) is a much larger separate effort — flagged in the issue thread.

Verification

• `cargo build -p ironrdp-connector` clean.
• `cargo clippy -p ironrdp-connector` clean (no new warnings; pre-existing duplicates persist).
• `cargo test -p ironrdp-connector --lib` — 0 tests in the lib, no regressions.
• No tests grep for the old error strings.

[Benoît Cortier (CBenoit)]

LGTM