Build: migrate clone dirs and workspaces to the new id scheme #65

Question

Build: migrate existing clone dirs and devpod workspaces onto the new id scheme.

Graduated from #55. Blocked by the parse-boundary build, which defines the id this migrates to.

Why renaming is safe (and why it's required)

Workspaces are git clones (workspace_clone.py:234), not worktrees: .git is a directory and the remote points at the .bare path, which does not move. So a plain mv is lossless — and uncommitted work survives, which is the one thing here that isn't cheaply recreatable. That is why the answer is rename-not-orphan for dirs.

The slice

• Rename old-scheme clone dirs on sight, under <cache>/<org>/<repo>/. Skip .bare. This machine's cache has 15+ affected dirs under blooop/bencher alone (main, w1, asdf1, test-dotfix, rerun30, update, tmp, ws1, ws2, w2–w6, …).
• Detect the old scheme structurally — a new-scheme leaf ends in - plus three consonant-vowel pairs. Known false-positive: a branch literally named foo-bexoza. Guard however is cheapest (e.g. confirm against the recorded branch in metadata.json rather than the name alone).
• Update metadata.json so WorktreeInfo.local_path / workspace_id match the renamed dirs — a rename that leaves metadata stale is worse than no rename.
• Devpod containers take new ids; old ones are orphaned. Print a one-line notice naming the count and a cleanup command, following the precedent in kinisi-robotics/kinisi_ros#9766 ("Note for anyone whose checkout id changed"). Do not delete containers automatically — they may hold state, and #9766's lesson is that reaping by id is exactly how the original incident destroyed a running sidecar.
• Idempotent: running twice renames nothing the second time, and an interrupted run leaves a resumable state (no half-renamed dir with stale metadata).

Acceptance

• A cache populated with old-scheme dirs is renamed once; a second run is a no-op.
• Uncommitted changes in an old-scheme clone survive the rename.
• .bare is never renamed.
• metadata.json agrees with the filesystem after the run.
• The orphaned-container notice fires exactly when there are orphans, and names a working cleanup command.