husk up with a name that already exists creates a second computer with the same name

[Hotragn]

husk up dev twice gives two running computers called dev. Not the reuse the homepage
describes, and not the error I expected instead.

$ husk up dev
✓ dev is up
  id         cmp_2p6pgx38a4gt

$ husk up dev
creating dev...
✓ dev is up
  id         cmp_gfevmyp99fg5

$ husk ls
name	id	provider	state	workdir	age
dev	cmp_2p6pgx38a4gt	local	running	/work	3m
dev	cmp_gfevmyp99fg5	local	running	/work	1s

The second up says "creating dev..." and means it.

Name resolution then quietly prefers the older one. Tagging each workspace by id makes it
unambiguous:

$ husk exec cmp_2p6pgx38a4gt -- 'echo FIRST  > /work/which.txt'
$ husk exec cmp_gfevmyp99fg5 -- 'echo SECOND > /work/which.txt'
$ husk exec dev -- 'cat /work/which.txt'
FIRST

So the second dev is unreachable by name from the moment it exists. And rm takes one
of the two:

$ husk rm dev --yes
destroying dev...
✓ destroyed dev

$ husk ls
dev	cmp_gfevmyp99fg5	local	running	/work	58s

That rm did its job properly — the first workspace was genuinely gone from disk, not
just from the record. It just did it to one of two machines while reporting on dev.

Why it matters past the tidiness

The homepage says "a stable key maps a conversation to the same machine, so its files
survive across tool calls without you tracking ids". On the MCP path that holds — one
session, one computer. On up it does not.

The worse half is cleanup. Someone who runs up dev twice and then rm dev has been told
the machine is destroyed, and one is still running with a workspace on disk. ls will
show it under a name that resolves to something else, so there is no sequence of commands
that makes the situation legible. It is #111 from the other direction: the two together
are how orphans accumulate without anyone doing anything wrong.

What I think the answer is

up on an existing name should return the existing computer or refuse. Silently creating
a shadow is the one option that cannot be right.

Returning the existing one matches the stable-key claim and matches what MCP already does
per session. Refusing is defensible if up is meant to be strictly a create verb, but
then it needs --reuse, and the error has to say that husk exec dev is probably what
was wanted.

Whichever it is, two computers with one name should be unreachable as a state, not merely
unlikely. If both are somehow allowed, ls needs to mark which one the name resolves to,
because right now the table gives no hint that one of those rows is unaddressable.

[Hotragn]

This is provider-divergent, and docker already does the right thing for the wrong reason.

husk up dkr twice on docker does not create a duplicate — it fails, because Docker will
not reuse a container name. So the behaviour this issue asks for already happens on one
provider, by accident of the engine rather than by any check in husk.

The failure itself is rough, though:

$ husk up dkr --provider docker     # second time
creating dkr...
error could not start a docker container: Command failed: docker run -d --name dkr
  --label husk.provider=docker --label husk.spec=eyJuYW1lIjoiZGtyIiwicHJvdmlkZXIiOiJkb2NrZXIifQ==
  --label husk.id=cmp_xw18wzraxas4 --cap-drop ALL --security-opt no-new-privileges
  --pids-limit 512 --read-only --tmpfs /tmp:rw,exec,nosuid,size=512m
  --tmpfs /run:rw,nosuid,size=16m --tmpfs /work:rw,exec,nosuid,mode=1777,size=2048m
  --cpus=2 --memory=2048m --memory-swap=2048m -w /work -u 1000:1000
  debian:bookworm-slim sleep infinity
docker: Error response from daemon: Conflict. The container name "/dkr" is already in use by
container "f739c4c46a95...". You have to remove (or rename) that container to be able to
reuse that name.

Run 'docker run --help' for more information

hint:  run `docker info` to check the engine is healthy
exit=1

Three things in that:

• The whole docker run line is dumped on the user, including the base64 spec label.
  Nothing in it is actionable for the person who typed husk up dkr.
• The hint is wrong. The engine is perfectly healthy; the name is taken. docker info
  will come back clean and tell them nothing. Same shape as the "check the path exists"
  problem in read_file and list_dir cannot follow a symlink, even one that stays inside /work #113 — a generic hint attached to a specific, well-understood failure.
• An id was allocated before the failure (cmp_xw18wzraxas4). Nothing was left behind,
  since the container never got created and docker is the source of truth for docker
  computers, but the id is burned.

The message a user wants is husk's own: dkr already exists, and husk exec dkr is
probably what was meant.

So the fix for this issue is a provider-independent check before creating, which gets
local to stop making duplicates and gets docker a message written by husk rather than
relayed from the daemon. Doing it only in the docker provider would fix the cosmetics on the
provider that is already safe and leave the data-losing one alone.