Fix HTTP transport cleanup during Unity reload

[JOY]

Summary

• Make HTTP transport shutdown idempotent when Unity domain reload cleanup reaches an already disposed HttpListener.
• Always clear transport running/listener state in a finally block after Stop().
• Treat Windows HttpListener address-in-use error codes/messages as retryable restart conditions.

Why

In Unity 6000.5 beta on Windows, a domain reload can call MCPServerService.StopSync after the HTTP listener has already been closed/disposed. The current Stop() path logs:

Cannot access a disposed object. Object name: 'System.Net.HttpListener'.

That leaves noisy console errors during reload/recompile and can make restart diagnosis harder. The same Windows environment can also surface address-in-use as 183/10048 or "Only one usage...", so this keeps the existing retry path effective there too.

Validation

• Ran the repository validation script from .github/workflows/ci.yml: passed.
• Ran git diff --check: passed.
• Verified the patch against the repro shape observed in Unity: duplicate/late Stop() after the listener has already been disposed.

[Winlifes]

Thanks for sending this fix. I incorporated the HTTP transport cleanup pieces into v0.3.6 and added a service-level lifecycle guard on top so overlapping startup paths share one in-flight StartAsync task instead of creating competing transports.

The final release also expands address-in-use detection for Windows (10048, 183, Only one usage...) and Mono/Unity (There's another listener for ...) messages, and cleans up partially initialized server state after failed/cancelled starts.

Validation before release included Unity compile/domain reload recovery and a port-occupied restart stress test where 12 concurrent starts reused one startup and recovered after the port was released.

Released here: https://github.com/FunplayAI/funplay-unity-mcp/releases/tag/v0.3.6

Closing this PR as superseded by the release commit on main, but the core issue you identified is fixed now. Appreciate the detailed repro and patch direction.

[JOY]

Actually the version I patched is v0.3.6. Still buggy there.

[Winlifes]

Thanks for clarifying. I misunderstood this as being fully superseded by v0.3.6, but I understand now that your repro/patch is against v0.3.6 and that the existing-listener case is still buggy there.

I will track the remaining issue in #6 and use #7 as the follow-up fix direction.