[dotnet-msbuild] Codex drops binlog MCP because tools is an array instead of a per-tool settings object

## Observed behavior

With `dotnet-msbuild` 0.1.9 installed and enabled, Codex CLI 0.153.4 rejects the bundled `binlog` MCP declaration. Skills load, but binlog tools are absent. The runtime logs:

```text
failed to parse plugin manifest MCP object server
server="binlog" error="invalid type: sequence, expected a map"
```

## Root cause

`plugins/dotnet-msbuild/.codex-plugin/plugin.json` includes:

```json
"mcpServers": {
"binlog": {
"type": "stdio",
"command": "dotnet",
"args": ["dnx", "Microsoft.AITools.BinlogMcp", "--yes", "--prerelease"],
"tools": ["*"]
}
}
```

In Codex, `tools` is a map of tool names to per-tool settings, not an allow-list. The configuration is rejected before the server starts. Omitting the optional field permits parsing and leaves `enabled_tools`/`disabled_tools` unset.

The installed manifest matches current upstream 0.1.9. The inline declaration is visible in [the manifest introduced by PR #1070](https://github.com/dotnet/skills/blob/be7b56028cf14cc5b9482b29959d7d96433bad05/plugins/dotnet-msbuild/.codex-plugin/plugin.json#L11). Codex documents per-tool settings separately from `enabled_tools` and `disabled_tools` in its [configuration reference](https://developers.openai.com/codex/config-reference).

## Minimal reproduction

These command-line overrides are transient; they do not edit the user's configuration or launch the MCP server:

```sh
codex -c 'mcp_servers.audit_binlog={command="dotnet",args=["dnx","Microsoft.AITools.BinlogMcp","--yes","--prerelease"],tools=["*"]}' mcp get audit_binlog --json
```

Observed exit code: **1**.

```text
Error: failed to load bootstrap configuration
Caused by:
invalid type: sequence, expected a map
in `mcp_servers.audit_binlog.tools`
```

Remove only the `tools` field:

```sh
codex -c 'mcp_servers.audit_binlog={command="dotnet",args=["dnx","Microsoft.AITools.BinlogMcp","--yes","--prerelease"]}' mcp get audit_binlog --json
```

Observed exit code: **0**; the returned server is enabled with the expected command/arguments and no tool allow-list or deny-list.

The installed manifest was also tested with its `type="stdio"` field retained; the same single-field failure/pass result holds.

## Expected behavior and suggested fix

The Codex-specific manifest should expose the bundled binlog server using configuration accepted by Codex. Remove the incompatible `tools` field from `.codex-plugin/plugin.json`. Other host manifests should retain their own supported semantics.

This is distinct from the path-resolution defect fixed by #1069 / #1070: the server declaration is now found, but its contents fail host deserialization. Earlier #738 covered installation under an older Codex version, not this currently reproduced server-configuration failure.

## Acceptance Criteria

- [ ] The Codex-specific declaration parses successfully and exposes the bundled binlog server.
- [ ] Other host manifests retain their supported tool-selection semantics.

## Validation

- [ ] Reject the incompatible tools array in a focused regression check.
- [ ] Verify plugin discovery and one binlog tool call after the fix.

### Existing coverage gap

`eng/skill-validator/tests/Check/PluginMcpManifestTests.cs` includes the incompatible `tools` array in its fixture. `DotnetMsbuildPluginExposesBinlogFromEveryManifest` only checks that the `binlog` property exists. `PluginDiscovery.TryGetManifestMcpServerNames` enumerates property names without validating each host's server schema, so those checks cannot catch this defect.

Please add validation that the shipped Codex server declaration is accepted by a supported Codex configuration parser, with a regression case for the incompatible array. Following the fix, verify actual plugin discovery and a binlog tool call; the failure/pass probe above proves configuration parsing only, not server startup or log processing.

## Environment

- `dotnet-msbuild`: 0.1.9
- Codex CLI: 0.153.4
- Codex desktop: 26.901.41600
- macOS arm64
- Reproduced: 2026-09-05