refactor: remove dynamic toolsets and deprecated closure constructor - #2512

`--dynamic-toolsets` / `ENABLE_DYNAMIC_TOOLSETS` and the three meta-tools
`enable_toolset`, `list_available_toolsets` and `get_toolset_tools` are gone,
along with the plumbing that existed only for them.

#179 argued the feature is unsound on the HTTP transport: MCP 2026-07-28 removed
protocol sessions, so `enable_toolset` cannot keep its promise that a toolset
stays enabled *for the caller* — the state lives on the shared toolset group, one
client's call rewrites what every other client of the process sees, and there is
no disable_toolset.

The reference implementation reached the same conclusion first, and went further.
GitHub removed the identical feature — same flag name, same three tool names — in
github/github-mcp-server#2512 (May 2026, +51/-942), citing reasons #179 arrived
at independently: local-only, never offered over the remote transport, and a
parallel registration path plus config plumbing and four inventory methods kept
alive for it. Confirmed against their current main: no `dynamic-toolsets` flag,
and code search for `DynamicToolset` returns nothing. Experimental behaviour
moved under `--features`, a different mechanism. So there is no ecosystem
convention left to stay consistent with, and this was already marked
Experimental here.

Removed:

  src/tools/dynamicTools/toolsets.ts       the three meta-tools
  src/utils/toolRegistrar.ts               createToolRegistrar
  src/dynamicToolsetPersistence.test.ts    pinned the shared-group mutation
  ToolRegistrar                            from types/tool.ts and lib.ts
  getToolset / enableToolset               from utils/toolsetUtils.ts

`registerDynamicTools` stays: `list_organizations` uses it, along with
`DynamicToolDefinition` and `DynamicToolsetGroup`.

Two things follow from nothing mutating the toolset group any more: the
`tools/list` cache hint is always published now, and the shared group is shared
only to avoid rebuilding the tool tree per request.

Breaking twice over. `ToolRegistrar` was exported from lib.ts, so library
consumers are affected as well as CLI users. And since yargs ignores unknown
flags, an existing setup would otherwise have started with a quietly different
tool list: the flag used to drop `all` from the enabled toolsets, so passing only
it went from no toolsets plus three meta-tools to every toolset enabled. Both the
flag and the environment variable now print a notice rather than failing, so a
config carrying `ENABLE_DYNAMIC_TOOLSETS: "1"` keeps starting.

toolsetUtils.test.ts covered only the two removed helpers and would have become
empty; rewritten to cover `buildToolsetGroup`, which had no direct tests.

Part of #179. The other half of that issue — the `fields` description payload
and whether --optimize-response should exist — is untouched, so it stays open.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>