fix(daemoncraft): wire embodiment toolset + daemoncraft platform into resolver chain

[Pablomonte]

Summary

The DaemonCraft canonical install (Path B, the embodied_plan single-body-tool architecture introduced 2026-05-09) is broken on a fresh origin/main install in a non-obvious way. Three companion hooks are missing from the toolset-resolver chain, so:

• The model receives tools=[] on every API call to Kimi-K2.6 (or any provider)
• It emits the tool invocation as raw text in the Minecraft chat:

  <AsciiProbe> ok. reviso. embodied_plan:1 {"intent":"Check my inventory…","autonomy_level":2,"deadline_seconds":30}
  

• The gateway log shows tool_turns=0 every turn, the embodied service at :7790 is never hit, and nothing physical happens.

This PR adds the three missing wiring entries. They are pure additions to the respective registries — no behavior change for any other platform or toolset.

The chain that's broken

Chat → daemoncraft platform                                        ← OK (gateway/config.py:112, 78a7c23e6)
     → ¿qué toolsets enable para esta platform?
       → PLATFORMS.get('daemoncraft')                              ← MISSING (patch 1)
       → platform_toolsets.daemoncraft = [embodiment, …]
     → ¿'embodiment' es un toolset configurable válido?
       → CONFIGURABLE_TOOLSETS                                     ← MISSING (patch 2) ← load-bearing
     → expand toolset to concrete tools
       → TOOLSETS['embodiment'] → ['embodied_plan']                ← MISSING (patch 3)
     → tools=[embodied_plan] → send to model
     → model emits structured tool_call → dispatch to /intent

Without any of the three, the chain breaks at its link. The user sees JSON in the chat, no action happens, and there's no error message — the failure mode is silent text leak.

The three patches (one-line each, except #3)

1. hermes_cli/platforms.py — register daemoncraft in the CLI platform catalog

("daemoncraft", PlatformInfo(label="⛏️  DaemonCraft", default_toolset="embodiment")),

Platform.DAEMONCRAFT is in gateway/config.py (since 78a7c23) but the CLI-side hermes_cli/platforms.py:PLATFORMS is a separate OrderedDict consumed by _get_platform_tools() and the TUI menus. Without the entry, PLATFORMS.get('daemoncraft') returns None, the resolver synthesizes a non-existent hermes-daemoncraft toolset name, and zero toolsets resolve.

2. hermes_cli/tools_config.py — list embodiment as a configurable toolset (load-bearing)

(\"embodiment\", \"🤖 DaemonCraft Embodied\", \"embodied_plan — single body tool dispatched to Gemma-Andy\"),

This is the patch that flips the gate. _get_platform_tools filters explicit profile toolsets by configurable_keys:

configurable_keys = {ts_key for ts_key, _, _ in CONFIGURABLE_TOOLSETS}
has_explicit_config = any(ts in configurable_keys for ts in toolset_names)
if has_explicit_config:
    enabled_toolsets = {ts for ts in toolset_names
                        if ts in configurable_keys
                        and _toolset_allowed_for_platform(ts, platform)}

The canonical DaemonCraft profile lists [embodiment, clarify, messaging]. clarify and messaging are in configurable_keys so has_explicit_config=True, but embodiment itself is dropped because it isn't. Result: the agent runs with {clarify, messaging} only, without embodied_plan — the entire body interface is invisible to the model.

3. toolsets.py — add the static embodiment toolset entry

"embodiment": {
    "description": "DaemonCraft body orchestration — exposes the single canonical tool `embodied_plan` …",
    "tools": ["embodied_plan"],
    "includes": []
},

tools/embodied_plan_tool.py:445 registers the toolset dynamically (registry.register(toolset=\"embodiment\")), and get_toolset() has a fallback to the dynamic registry — but the fallback labels it \"Plugin toolset\" / \"MCP server\" and code paths that read TOOLSETS.get(\"embodiment\") directly (without falling back) treat it as absent. The explicit entry makes it a first-class built-in, consistent with minecraft legacy and every other toolset.

Smoke test

Profile config (canonical DaemonCraft):
```yaml
model:
default: kimi-k2.6
provider: kimi-coding
toolsets: [embodiment, messaging]
platform_toolsets:
daemoncraft: [embodiment, clarify, messaging]
platforms:
daemoncraft:
enabled: true
extra:
bot_api_url: http://localhost:3001
bot_username: AsciiProbe
embodied_service_url: http://localhost:7790
```

Then:
```bash
HERMES_HOME=~/.hermes/profiles/daemoncraft-base hermes gateway run -v
```

Send @AsciiProbe contame qué ves alrededor in the Minecraft chat:

	Before (origin/main)	After (this PR)
Gateway log tool_turns	0	≥1
Embodied service /intent request	not hit	hit, 8.4s Ollama round-trip
Bot chat response	raw JSON: `embodied_plan:1 {"intent":...}`	natural prose: `"vi carbón cerca. ¿quieres que mine un poco, o preferís que te siga?"`
tools=[] in dumped request	count: 0	count: 1 (`embodied_plan`)

Reproduced both sides on a fresh `origin/main` clone with the DaemonCraft profile from `agents/embodied-service/profile-templates/` (mirror in the daemoncraft repo).

No-op for other platforms

All three patches are pure additions to their respective dicts:

• New `PlatformInfo` row in `PLATFORMS` OrderedDict
• New 3-tuple entry in `CONFIGURABLE_TOOLSETS`
• New key in `TOOLSETS` dict

No existing entries modified, no logic branches changed, no dependencies added. Telegram, Discord, CLI etc. resolve identically before and after.

Why this was missed

The commits that introduced the canonical DaemonCraft architecture landed in pieces:

• Platform enum: `78a7c23e6 fix(gateway): register daemoncraft platform + handle kimi tool_choice with thinking`
• Tool registration: `tools/embodied_plan_tool.py:445` does `registry.register(toolset="embodiment")`

But the integration through the CLI-side toolset/platform resolver (which is what's actually consulted at gateway runtime) was never wired. The model's "tool emitted as raw text" symptom is silent — no error log surfaces in either the gateway or the embodied service — so it slips past manual testing.

Test plan

• Reproduce `tool_turns=0` + JSON text leak on a fresh `origin/main` install
• After patches: confirm `tool_turns≥1`, embodied service hit, natural chat response
• Confirm `hermes tools list` now shows `embodiment` in built-in toolsets (previously absent)
• Confirm `hermes profile use daemoncraft-base + hermes gateway run` end-to-end with canonical profile