fix: restart Windows agent on plugin version drift

[qtcqtc]

Closes #193.

The Windows launcher already loads plugin-version.ps1, but its healthy-process fingerprint omits the resulting MONK_PLUGIN_VERSION. When a plugin release reuses the same Agent binary, the existing companion therefore stays alive with stale release attribution.

This change:

• snapshots the rendered plugin version after loading plugin-version.ps1;
• persists it in the Windows launcher state file;
• includes it in the exact fast-path comparison;
• updates every generated PowerShell launcher copy;
• adds an isolated Windows regression with a fake healthy companion.

The regression proves all three lifecycle cases:

1. the first process inherits old-version;
2. an unchanged second launch reuses it;
3. changing only the rendered version to new-version restarts once and updates state.

Verified on Windows 11 / Windows PowerShell 5.1:

plugin_version_restart_status=pass launches=2
Windows block-monk fallback tests passed.

All generated PowerShell launcher copies are byte-identical and git diff --check passes.

The unrelated readiness-timeout test harness failure on Windows PowerShell 5.1 is tracked in #191 / #192.

[nooga]

Thanks for the PR — the fix itself is correct and complete across all three render copies (read and write sides of the fingerprint stay symmetric, matching the existing autospin_url pattern). The gap is that the new regression test isn't wired into install-e2e.yml, so it provides no durable protection going forward — every sibling fix in this area (including #138, which covers this same field plus more) wires its tests into that workflow. Closing as inadequate as submitted; we'll fold the equivalent fix into a combined patch for this fast-path fingerprint gap.