feat(auth): Unity plugin dual-hash instance metadata + B10 port derivation (auth-fixes d1)

[IvanMurzak]

Summary

Land the Unity-plugin share of auth-fixes task d1: the editor's hub instance-metadata handshake now sends the v2 project-path hash AND the legacy v1 hash (dual-hash transition), and the deterministic local-port derivation stops hashing the raw, untrimmed Environment.CurrentDirectory (defect B10) — it now uses the shared ProjectIdentity v2 normalization so the port stays in lock-step with the routing pin.

Context

Part of the auth-fixes design (Wave 2). Per k1's code-trace (design doc 01-current-architecture.md §7), the B11 "agent only sees 3 tools" root cause is an audience-validation asymmetry at the server/LIB instance-registration validator, so the actual B11 fix lands in shared/MCP-Plugin-dotnet (task c2), NOT in the Unity plugin. The Unity plugin's own behaviour is correct. This task is therefore the Unity-side share only:

• Dual-hash relies on the c1 LIB primitives (ConnectionInstanceMetadata with projectPathHashLegacy, ProjectIdentity.NormalizeV2/DerivePortV2/DeriveProjectPathHashV2), which landed in MCP-Plugin-dotnet Instant executable script with Roslyn - Update `0.11.0` #165 — one commit after the released McpPlugin 7.1.1 the plugin currently vendors. So the plugin must compile against a local build of that LIB commit (dev-DLL, cross-repo dependency mode); the NuGet pin bump is deferred to the release wave (k3).
• B5 defect (Windows CLI enroll-pin vs plugin forward-slash hash divergence) is addressed by dual-hash; the v2 pin normalizes \→/.

Proposed approach

1. Dual-hash metadata — ProjectInstanceService.BuildMetadata already routes through ConnectionInstanceMetadata.Create, which (in the c1 LIB) emits both projectPathHash (v2) and projectPathHashLegacy (v1). Vendor a dev-build of McpPlugin.dll + McpPlugin.Common.dll (netstandard2.1, Release) from the LIB dual-hash commit into Assets/Plugins/NuGet/ across the plugin + all 5 Unity-Tests projects so the handshake actually carries both hashes. No plugin source change needed for the send path; window pin/hash still derive from the single ProjectRootPath string.
2. B10 — Runtime/UnityMcpPlugin.cs GeneratePortFromDirectory() derives the port via ProjectIdentity.DerivePortV2(...) (v2 normalization: trim trailing separators, \→/, lowercase) instead of hashing the raw Environment.CurrentDirectory. Add a unit test.
3. Add tests: dual-hash visible in the handshake payload; B10 port normalization (backslash/forward-slash/trailing-slash converge, matching the v2 golden vectors).

Acceptance criteria

• Instance-metadata handshake carries both v2 and legacy v1 projectPathHash (test evidence).
• Port derivation normalized via ProjectIdentity v2 + unit test.
• Plugin CI green.
• (Deferred to k2 — gated on the c2 LIB fix) k1's E2E repro: window Authorize → agent sees engine tools, not 3.

Filed automatically by the implement-task pipeline (auth-fixes Wave 2, task d1).