hyperv-iso: WinRM connect step fails with WS-Man "InvalidSelectors"/ShellId fault since v1.1.5 (regression from v1.1.4)

### Description

`hyperv-iso` builder's WinRM connectivity check (the "Waiting for WinRM to become available..." step) fails permanently with a WS-Man `InvalidSelectors` fault when using **v1.1.5**, but works correctly on **v1.1.4** with an otherwise identical configuration.

### Environment

- packer-plugin-hyperv: v1.1.5 (broken) vs v1.1.4 (working) — confirmed via version bisection
- Guest OS: Windows 7 SP1 x64
- Communicator: winrm (Basic auth, AllowUnencrypted=true, port 5985)
- Host: Windows Server 2019 / Windows 11 (reproduced on both)
- Packer core: reproduced on multiple versions (1.8.2 through current), so this is isolated to the plugin version

### Symptom

After the VM boots and WinRM is confirmed reachable and correctly configured (verified independently via `Test-WSMan`/`Invoke-Command` from the host, and via a standalone Go program using the same `masterzen/winrm` client library directly — both succeed every time), Packer's own connectivity-check loop never succeeds. It logs, every ~5 seconds, indefinitely:

```
[INFO] starting remote command: powershell.exe -EncodedCommand ...
[INFO] command '...' exited with code: 1
Communication connection err: received error response
```

### Root cause (confirmed via packet capture)

A Wireshark capture of the actual WinRM traffic on port 5985 shows:

1. `POST /wsman` (CreateShell) → `200 OK` (shell is created successfully, ShellId is returned)
2. **Immediately following**, `POST /wsman` (Command) → `HTTP/1.1 500`, body:

```xml

s:Senderw:InvalidSelectors
The WS-Management service cannot process the request because the request did not contain all required selectors.

http://schemas.dmtf.org/wbem/wsman/1/wsman/faultDetail/InsufficientSelectors

The Windows Remote Shell cannot process the request because it requires the following selector: ShellId. Retry with the correct selector.

```

The `ShellId` returned by the successful `CreateShell` response is not being carried over into the subsequent `Command` request by this specific connectivity-check code path. A standalone Go program using the exact same `masterzen/winrm` client library version and calling `client.Run(cmd, ...)` directly against the same VM, at the same moment in time, succeeds every time — so this looks like a bug in how the plugin's own connect/health-check step constructs/reuses the shell reference, not in the vendored `masterzen/winrm` library itself.

### Bisection

- `v1.1.4`: works correctly, `Connected to WinRM!` reached, provisioning proceeds.
- `v1.1.5`: fails every time, indefinitely, with the fault above.
- No other variable changed between the two test runs (same unattend.xml, same bootstrap script, same VM, same host).

Given the only functional change between v1.1.4 and v1.1.5 is the packer-plugin-sdk bump (0.6.1 → 0.6.4, landed together with #149 "Fixed sporadic issues affecting the PowerShell provisioner"), that SDK bump / PR looks like the most likely source of the regression.

### Reproduction

Happy to provide the full unattend.xml, PACKER_LOG output, and the Wireshark capture/exported HTTP streams if useful.

[windows-7-x64-unattend-for-issue.xml.tpl.txt](https://github.com/user-attachments/files/31876754/windows-7-x64-unattend-for-issue.xml.tpl.txt)
[packer-1_1_5-sanitized.log](https://github.com/user-attachments/files/31876750/packer-1_1_5-sanitized.log)
[packer-1_1_4-sanitized.log](https://github.com/user-attachments/files/31876749/packer-1_1_4-sanitized.log)
[wireshark-http500-sanitized.txt](https://github.com/user-attachments/files/31876751/wireshark-http500-sanitized.txt)

Compare the v1.1.4 and v1.1.5 changes, starting with the packer-plugin-sdk bump and the hyperv-iso WinRM connectivity-check path. Reproduce with the supplied sanitized logs and Wireshark capture, then verify that the v1.1.5 check preserves the CreateShell ShellId, reaches “Connected to WinRM!”, and no longer reports InvalidSelectors.

Written by the indexing model from the issue text.