PSRP: dynamic runspace pool sizing (Set Max/Min, GetAvailable, Reset)

## Gap
Post-open runspace-pool management is absent (message-type IDs reserved, no flows). These matter once we support more than one concurrent pipeline per pool.

## Missing messages
- `SET_MAX_RUNSPACES`, `SET_MIN_RUNSPACES`
- `GET_AVAILABLE_RUNSPACES` → `RUNSPACE_AVAILABILITY` response
- `RESET_RUNSPACE_STATE`

(Currently min/max are only fixed at pool open via INIT/CONNECT — enum IDs at `crates/ironposh-psrp/src/cores.rs:38`.)

## Required
- Implement the request messages + the `RUNSPACE_AVAILABILITY` response parsing (carries a ci/long response).
- Client-core APIs: `set_max_runspaces`, `set_min_runspaces`, `get_available_runspaces`, `reset_runspace_state`, correlated by the `ci` (call id).
- Track pool capacity to allow >1 in-flight pipeline (prerequisite/related work).

## Acceptance
- Tests asserting set/get round-trips against the live server; reset returns the pool to a clean state.

## References
- psrpcore `src/psrpcore/_client.py` (`set_max_runspaces`/`set_min_runspaces`/`get_available_runspaces`/reset).
- Native C# `RunspacePoolInternal.cs` (SetMax/SetMin/GetAvailableRunspaces), `EncodeAndDecode.cs`.

Start with the reserved message-type IDs in crates/ironposh-psrp/src/cores.rs:38, then compare the referenced psrpcore client APIs and Native C# RunspacePoolInternal.cs and EncodeAndDecode.cs. Trace the existing INIT/CONNECT flow and client-core call correlation before running the live-server tests. Done means the four APIs, availability response parsing, capacity tracking, and round-trip/reset acceptance tests work.

Written by the indexing model from the issue text.