Refinement: dotnet-msbuild binlog MCP failure is invisible to the agent; add a SessionStart preflight hook #1312

Plugin: plugins/dotnet-msbuild (0.1.11)

Scenario: A user tells their AI assistant "help me install dotnet-msbuild". The plugin installs, but the binlog MCP server never connects. The user and the assistant both see only:

Failed to reconnect to plugin:dotnet-msbuild:binlog: CONNECTION_CLOSED

Neither has a way to find the cause, so the assistant cannot help the user fix it.

Reproduction: Workspace nuget.config contains <clear /> plus one private mirror that lacks Microsoft.AITools.BinlogMcp. Running the plugin's launch command by hand shows the real error:

$ dotnet dnx Microsoft.AITools.BinlogMcp --yes --prerelease
A version higher than 0.0.0-0 of package microsoft.aitools.binlogmcp is not found in NuGet feeds <mirror>.
(exit 1)

That message is lost at the stdio boundary. The host reports only CONNECTION_CLOSED.

Expected: The assistant is told, at session start, that the binlog MCP server cannot start, why, and what to do about it, so it can guide the user.

Proposed fix: Add a SessionStart hook to the plugin. It runs a cheap preflight for the same resolution dnx will do (e.g. dotnet package search Microsoft.AITools.BinlogMcp --prerelease, or dotnet dnx against the package with a short timeout). On failure it emits additionalContext such as:

dotnet-msbuild: the binlog MCP server will not connect. Microsoft.AITools.BinlogMcp was not found in the NuGet feeds configured for this workspace: <feeds>. Tell the user. Options: add the package to the feed, add nuget.org to nuget.config, or install it globally from a feed that has it and register binlog-mcp as an MCP server.

Context injected by a hook is the only channel the assistant is guaranteed to read. The failing MCP connection itself carries no diagnosis.

Optional: Wrap the launch in a script that captures dnx stderr and returns it as the MCP connection error, so /mcp shows the real message too.