fix(mcp): accept either tool-name form in config, CLI, and doctor

[Aaronontheweb]

Summary

Follow-up to #1153. That PR fixed the LLM-vs-operator audience split for the runtime hot path, but three operator-facing surfaces still did exact-string matching on tool names and would silently ignore the LLM-facing alias if an operator pasted it:

1. ToolApprovalConfig.TryGetExplicitMode — runtime override lookup. An operator who wrote notion__create-pages (the form they saw in audit logs or transcripts before refactor(mcp): make canonical/LLM-facing tool name boundary type-enforced #1153 tightened the surfaces) got no override applied; the tool silently fell through to DefaultMode. Security misconfiguration risk.
2. netclaw approvals CLI (list --tool, revoke --tool, revoke --all --tool, trust-verb --tool) — the on-disk store is canonical-keyed; the LLM-facing alias passed as --tool matched nothing. trust-verb --tool notion__create-pages ... would also persist under the alias key, creating a dead grant the runtime gate would never find.
3. ToolAudienceProfilesDoctorCheck — the "MCP server reachable on Personal without approval default" scan only recognized {server}/ prefixes in ToolOverrides. Operators with sanitized-form override keys were warned to add coverage they had already (futilely) configured.

Fix

Pure-string helper on LlmFacingToolName:

public static string? TryReverseSanitizedToCanonical(string name)

Returns the canonical form ({server}/{tool}) when the input looks like the sanitized alias ({server}__{tool}); returns null for first-party names, already-canonical inputs, and malformed shapes (__foo, foo__). The convention "first-party tool names never contain __" makes this unambiguous in practice; a future first-party tool that legitimately needs __ would need the helper to grow a registry-aware overload (documented in remarks).

Then:

• ToolApprovalConfig.TryGetExplicitMode inlines the same reverse-resolution (no Tools.Abstractions dep from Configuration — wrong layer direction) so the runtime hot-path lookup tries both forms with the canonical-exact-match keeping precedence when both shapes exist.
• ApprovalsCommand normalizes the --tool flag at all four call sites: list filter, revoke single-pattern filter, revoke-all store call, and trust-verb persistence (canonical only — so the grant the operator just made is something the runtime can actually consume).
• ToolAudienceProfilesDoctorCheck accepts both {server}/ and {server}__ prefixes when scanning ToolOverrides.

Test plan

• dotnet build — clean
• dotnet test — 1968 Actors / 743 Cli / 333 Configuration tests pass
• New unit coverage:
  • LlmFacingToolName.TryReverseSanitizedToCanonical_* — round-trip for MCP aliases, identity for first-party / canonical / empty, null for malformed shapes
  • ToolApprovalConfig.TryGetExplicitMode — alias key resolved, canonical-exact-match precedence
  • ApprovalsCommand — list filter, revoke-all, trust-verb persistence under canonical
  • ToolAudienceProfilesDoctorCheck — alias-prefix coverage
• dotnet slopwatch analyze — no new violations
• ./scripts/Add-FileHeaders.ps1 -Verify — all files have headers

Out of scope

JSON schema (netclaw-config.v1.schema.json) still validates ToolOverrides keys only by value-shape — neither form is rejected. With this PR both forms work at runtime, so schema-level enforcement is no longer urgent. Doctor remains the surface where misuse would be flagged; a future --fix resolver could rewrite alias keys to canonical for operator hygiene.