fix(resolver): one-click recovery for stale PackageCache compile deadlock

[YatogamiRaito]

Summary

• Adds a Force Reimport Package Cache menu item next to the existing Force Resolve NuGet DLLs one under Tools > AI Game Developer > Dependencies. It deletes this package's own extracted copy under Library/PackageCache/com.ivanmurzak.unity.mcp@* and calls UnityEditor.PackageManager.Client.Resolve() to force a genuine re-extraction.
• Documents the recovery path (both menu items, plus the manual fallback) in the README under a new Troubleshooting section.

Motivation

Hit this in a real project (Unity 6000.7.0a2): Packages/manifest.json had been bumped to a newer plugin version while the Editor was closed. On next launch the Console showed CS0115: '...CredentialProvider': no suitable method found to override in UnityMcpPlugin.Config.cs — the on-disk NuGet DLLs (Assets/Plugins/NuGet) were stale relative to what the new source expected.

NuGetDependencyResolver's self-heal paths never got a chance to run:

• [InitializeOnLoad] requires a successful domain reload, which Unity refuses while any script has a compile error.
• The registeredPackages event workaround from NuGet resolver doesn't trigger after package upgrade when project has compile errors — [InitializeOnLoad] blocked, no domain reload #707 only helps for a package transition that happens while the Editor is already running — it doesn't apply to a cold start where the mismatch already exists on disk.

Manually copying the correct-version DLLs into place fixed the CS0115, but revealed a second, unrelated issue: three .cs files under this package's Editor/Scripts/Services/ (AccountCredentialService.cs, ProjectInstanceService.cs, UnityTokenRefresher.cs) were present on disk with valid .meta files but were silently missing from the actual Roslyn compile args (verified by inspecting the generated .rsp file directly), producing CS0103 errors that look like a source bug but aren't. Neither AssetDatabase.Refresh() nor a full Editor restart cleared this — only deleting Library/PackageCache/com.ivanmurzak.unity.mcp@<hash> and forcing Client.Resolve() did.

This PR doesn't attempt to fix Unity's own domain-reload-blocks-on-any-compile-error behavior or its AssetDatabase import gap (both are outside this package's control), but it does give users a documented, one-click way out instead of having to reverse-engineer the recovery by hand.

Test plan

• Verified the new menu action end-to-end against a live, real-world project (not this repo's own test projects): wrote the file into the project's resolved package cache via the plugin's own script-update-or-create tool (Roslyn-validated, waits for the resulting Unity recompile) — compiled clean.
• Invoked NuGetResolverMenu.ForceReimportPackageCache() via reflection through the plugin's own script-execute tool against a healthy package cache, confirming it's safe to run when nothing is actually broken (idempotent): Console showed the expected [NuGet] log sequence (delete → RecompileGate.Reset() → Client.Resolve() requested).
• Confirmed Unity Package Manager re-extracted Library/PackageCache/com.ivanmurzak.unity.mcp@<hash> afterward with the same content/fingerprint, the Editor recompiled without errors, and the plugin's own MCP connection came back up and answered tool calls again.
• Not covered: an automated EditMode/PlayMode test, since this is an Editor-only, disk/UPM-side-effecting menu action outside what the existing test harness (which runs pre-resolved projects) exercises.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.