WinRM: complete Enumerate/Pull/Get/Put/Identify operations

## Gap
Several WS-Management operations exist only as body-slot/type stubs and are not serialized/driven. Low priority for a PSRP client, but needed for completeness (shell enumeration, server config introspection, capability probing).

## Current state (`crates/ironposh-winrm/src/ws_management/body.rs`)
- `EnumerateValue::append_to_element` is `todo!()` — Enumerate/Pull not serialized.
- `Get`/`Put` — `WsAction` + body slots exist, no concrete value types/usage.
- `Identify` — body slot + tag exist, no client-driven request flow.

## Required
- **Identify** (cheapest, useful first): send a `wsmid:Identify` and parse `IdentifyResponse` (protocol version, product vendor/version) — handy for capability probing.
- **Enumerate/Pull**: implement `EnumerateValue` serialization + `Pull` to list active shells.
- **Get/Put**: concrete request/response for WS-Man config resources.

## Acceptance
- Per-op: a request round-trips against the live server and parses the response (Identify first).

## References
- pypsrp `wsman.py` (`enumerate`/`pull`/`get`/`put`; note pypsrp also lacks a top-level `identify()`).
- MS-WSMV / WS-Management Identify + Enumeration.

Start in crates/ironposh-winrm/src/ws_management/body.rs, where EnumerateValue serialization is still a stub and the Get, Put, and Identify body slots are defined. Begin with the Identify flow, using the pypsrp wsman.py reference and MS-WSMV/WS-Management references to understand the request and response. Done means each operation round-trips against a live server and parses its response.

Written by the indexing model from the issue text.