#4238: Fix/docker migration atomicity

1. The Problem Migration Loop: The core logic tried to rename .clawdbot to .moltbot. In Docker, these are often bind mounts from the host. Renaming a mount point fails with EBUSY, causing the container to crash and restart in a loop. Permission Denied (EACCES): The container runs as a non-root user (node). If the host directories or Docker volumes were created by root (common during initial start), the app crashes when trying to write to cron, canvas, or logs. Usability: The moltbot CLI was not in the global PATH inside the container, requiring confusing commands like node dist/index.js. Robustness: src/infra/state-migrations.ts now safely skips migration if it hits EBUSY (common in Docker), preventing crashes. Atomicity: docker-compose.yml now uses named volumes for verified isolation and permissions, rather than host bind mounts. DX: Dockerfile now includes a global moltbot CLI symlink for easy access via docker exec. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR hardens Docker state migration by skipping auto-migration when `fs.renameSync` fails with `EBUSY` (common with bind mounts), and reshapes the Docker Compose setup toward using named volumes plus a direct `node /app/moltbot.mjs gateway` command. Main concerns are around ecosystem consistency: `docker-compose.yml` removed the `moltbot-cli` service and no longer consumes `CLAWDBOT_CONFIG_DIR`/`CLAWDBOT_WORKSPACE_DIR`, but `docker-setup.sh`, its tests, and `docs/install/docker.md` still assume those exist and are used. This will break the documented/automated Docker setup flow unless updated in tandem. Additionally, the build-time `chown` in the Dockerfile won’t correct ownership for mounted volumes/binds at runtime. <h3>Confidence Score: 2/5</h3> - This PR has user-facing Docker workflow breakages that should be addressed before merging. - The code change in state migration is narrow and low-risk, but the Docker Compose changes appear inconsistent with existing setup script, tests, and docs (notably removal of `moltbot-cli` and unused exported env vars), which will likely break common workflows. There’s also a mismatch between the stated permission fix and what build-time ownership changes can actually accomplish with runtime mounts. - docker-compose.yml, docker-setup.sh, docs/install/docker.md, src/docker-setup.test.ts, Dockerfile <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->