fix(wrapper): resolve built-in MCP defaults from the configured command, not the section name

[Lafnaps]

Define a second instance of a known CLI under its own section — the setup multi-instance support invites:

[agents.claude2]
command = "claude"

and the wrapper injects no MCP config at all. _resolve_mcp_inject() looks up _BUILTIN_DEFAULTS[agent] by the config section name, so claude2 misses the table. The agent launches fine, but without the agentchattr MCP server: no chat tools, never answers a mention, and nothing anywhere says why. Same story for codex/gemini/kimi/kilo under custom section names.

The fix keys the defaults off what the section actually launches: take the basename of command, strip .exe/.cmd/.bat, lowercase, and require an exact match against the defaults table. Deliberately no prefix or substring matching — command = "claude-compatible" or a wrapper script resolves to nothing rather than to the wrong provider. Explicit mcp_inject in the section still wins outright, and per-section mcp_* keys still overlay the resolved defaults, as before.

This got more relevant with 0e8928e: [agents.antigravity] launching agy is exactly a section whose name differs from its executable (it works because it ships explicit mcp_* config; second instances defined by users don't get that treatment).

Six new tests in tests/test_identity_contract.py: a named claude section gets the claude flag defaults end-to-end through _build_provider_launch (writes the --mcp-config file with bearer auth); a full-path C:\Tools\codex.exe resolves the codex proxy defaults; a bare claude.exe resolves; explicit mcp_inject beats command-derived defaults; partial mcp_* keys merge over them; unknown claude-compatible resolves to {}. python -m pytest -q tests/test_identity_contract.py → 24 passed. Full suite: 87 passed (81 on current main).