fix(bot/place): auto-shift placement target out of bot's own bounding box

[Pablomonte]

Summary

The `place` action in `agents/bot/server.js` (canonical embodied-side dispatcher target for `place_block` tool calls) silently fails when the requested `(x, y, z)` is inside the bot's own bounding box. The Minecraft server rejects `_genericPlace` calls that would clip the player hitbox, but the rejection is a no-op (no exception), so the only signal is the post-place `blockAt()` check failing with the opaque:

"Placed crafting_table at (X, Y, Z) but block did not materialize. Retry or choose different coordinates."

The captain LLM then has no useful information — Gemma-Andy retries the same coordinates, hits the same silent reject, and after a few loops the bot tells the player "no puedo construir, el sistema sigue roto".

Repro (live trace from a Hermes-K2.6 + DaemonCraft session)

```
Captain → embodied_plan(intent=
"Place a crafting_table near my position, then craft a stone_shovel.")
→ Gemma-Andy plan: [place_block(crafting_table, x=bot.x, y=bot.y, z=bot.z),
craft_item(stone_shovel)]
→ bot place action: target == bot feet cell → silent server reject
→ materialize check fails → throws "did not materialize"
→ craft_item then fails: "needs crafting table nearby"
→ captain to player: "no puedo construir"
```

The fix

Before the existing occupied / neighbour-search logic in `place`, check whether the floor of the requested target equals the bot's feet cell (`floor(pos)`) or head cell (`feet + 1`). If yes, pick the first candidate from:

```
[(+1,0,0), (-1,0,0), (0,0,+1), (0,0,-1), ← four horizontal adjacents
(0,+2,0), ← two above feet (clear of head)
(0,-1,0)] ← below feet (rare, bot floating)
```

…that is:

• not in the bot's own occupied cells
• `air` / `cave_air`
• has at least one solid neighbour to place against

…and rewrite `(x, y, z)` to that. Log the shift so operators see it in dispatch traces:

```
[place] target (X,Y,Z) overlaps bot — shifted to (X',Y',Z')
```

If no candidate fits, raise a clear error explaining the placement cannot proceed without first moving the bot — not the opaque `did not materialize` the captain previously had to guess at.

After

```
Captain → embodied_plan(intent=
"Place a crafting_table near my position, then craft a stone_shovel.")
→ Gemma-Andy plan: [place_block(..., x=bot.x, y=bot.y, z=bot.z),
craft_item(stone_shovel)]
→ bot place: overlap detected → shifted to (bot.x+1, bot.y, bot.z)
→ _genericPlace succeeds, materialize check passes
→ craft_item: finds crafting_table within 4 blocks → succeeds
→ captain to player: "listo, pala de piedra hecha"
```

Companion PRs (build-with-confidence stack)

• This PR — bot-side placement guard
• nicoechaniz/DaemonCraft#16 — gemma_policy.py: add `craft` category, narrow `inventory_query` keyword
• nicoechaniz/hermes-agent#8 — same policy patch on the vendored copy
• nicoechaniz/hermes-agent#7 — toolset wiring so `embodied_plan` is dispatchable in the first place

These four together close the loop from "captain emits build/craft intent" to "action succeeds in the world" for fresh DaemonCraft installs.

Test plan

• Repro the failure: bot standing at `(0,71,0)`, ask captain to place a crafting_table — see "did not materialize".
• Apply the patch, restart bot, repeat — see `[place] target (0,71,0) overlaps bot — shifted to (1,71,0)` in log; block materializes; follow-up craft succeeds.
• Edge: bot in a 1-wide tunnel (no horizontal neighbours) — should fall back to `above-head` candidate. Manual test pending.
• Edge: bot floating mid-air with no solid neighbours anywhere — should raise the clear "no adjacent empty cell has a solid neighbour" error, not "did not materialize".

Scope

No new dependencies. No API change — `place` still accepts the same `{block, x, y, z}` shape. Logs are additive. `place_fill` and `place_sign` are intentionally not touched in this PR; `fill_volume` may need the same guard but its semantics differ (bulk fill across a rectangular region) so it warrants its own analysis.