Fix IIS handler Windows detection — accept legacy long-form OS strings

Summary

• IISDeployActionHandler.EnsureWindowsTentacleTarget used strict equality with the canonical short form "Windows" emitted by modern Tentacle agents via AgentOperatingSystems.Windows. Older Tentacle binaries (or cache entries seeded before the canonical-constant refactor) write the value of Environment.OSVersion.VersionString (e.g. "Microsoft Windows NT 10.0.19045.0") into the same "os" metadata field. The validator rejected those agents as "not Windows" and surfaced a misleading error
• New LooksLikeWindowsOsString helper accepts both forms: the canonical "Windows" AND any string starting with "Microsoft Windows". Anchored on StartsWith, not Contains — explicitly tested to NOT false-positive on strings like "LinuxOnWindowsSubsystem" or "not-a-windows-host"
• 21 new theory cases covering: canonical short form, four legacy long forms across Win10 22H2 / Win11 23H2 / Server 2019 / Server 2022, case sensitivity, non-Windows markers (Linux/macOS/Darwin/FreeBSD/Unknown), null/empty edges, anchoring false-positive prevention. Total IIS handler tests: 13 → 34

Real-world failure mode

A user with a fully-functional Windows 10 Tentacle (build 19045 = Win10 22H2) hit this exact error at deploy dispatch:

Action 'Deploy to IIS' (type 'Squid.DeployToIISWebSite') in step 'Deploy to IIS'
requires a Windows Tentacle target. The configured target reports
'Squid.Tentacle.OS'='Microsoft Windows NT 10.0.19045.0'.

The remediation guidance ("run a health check to refresh the cache") didn't help because the cache was already populated; the validator was too narrow.

Test plan

• dotnet build Squid.sln → 0 errors
• dotnet test --filter IISDeployActionHandlerTests → 34/34 pass, 293ms
• CI: unit + integration tests
• Manual smoke (post-merge): retry the user's deploy against the same Win10 19045 Tentacle, confirm action passes the gate