explain-disabled-tools: surface allow/block-list-blocked tools as a disabled reason

[jlrobins]

Problem

explain-disabled-tools walks ToolHandlerRegistry.allHandlers() and reports each tool's
predicate verdict, but it has no knowledge of the operator's --allow-tools / --block-tools
filter. A tool the operator explicitly blocked is therefore invisible to (or mis-explained by)
the diagnostic — the symmetric "why is this tool missing?" answer "because the operator's
allow/block list excluded it" is never given.

This is the filter/inventory-tool mismatch flagged while implementing list-connections (#536).

Now-available groundwork

#536 relocated the resolved allow/block-list onto ServerRuntime as the single source of truth,
exposed via runtime.isToolAllowed(name). explain-disabled-tools can now consult the same
method to fold a filter-blocked bucket into its report.

Proposed work

• Add a ToolDisabledReason (or equivalent grouping key) for "excluded by the operator's
  allow/block list".
• In buildToolGatingReport (tool-availability.ts), classify a tool as filter-blocked when
  runtime.isToolAllowed(name) is false, ahead of the predicate verdict.
• Cover the new bucket in the handler/report tests, pinning the specific reason text.

Relationships

• Child of Epic: Multi-connection support #532
• Builds on Discovery tool: list-connections #536