fix(completion): complete the uninstall command and its targets

[clawedassistant26]

The bug

uninstall shipped in #150 (af572d5) and moshcode help documents it:

moshcode uninstall <engine|tool>     take one back off this machine

But it was never added to CORE_CLI_COMMANDS in src/cli-schema.mjs. Shell completion is generated from that roster, so tab completion does not know the command exists. Same for the remove alias, which bin/moshcode.mjs:294 dispatches alongside it.

main is currently red because of this. completion.test.mjs:68 already guards exactly this ("completion schema covers every explicitly dispatched CLI command") and has been failing since #150 landed:

not ok 240 - completion schema covers every explicitly dispatched CLI command
  error: 'uninstall is dispatched but missing from completion'

Reproduced before touching anything

Sourcing the real generated script in a real bash and calling the real completion function on unmodified main:

what you type	suggestions
moshcode un<TAB>	(nothing)
moshcode uninstall <TAB>	(nothing)
moshcode remove <TAB>	(nothing)

moshcode completion bash, zsh and fish each contained zero occurrences of uninstall or remove.

After the fix, same harness:

what you type	suggestions
moshcode un<TAB>	uninstall
moshcode uninstall <TAB>	aider c0mpute claude codex coinpay doctl doppler gemini gh opencode privacycode railway secrets supabase tailscale turso ugig
moshcode uninstall claude --<TAB>	--yes --dry-run

The fix

• src/cli-schema.mjs: add uninstall and its remove alias to CORE_CLI_COMMANDS.
• src/completion.mjs: add an uninstall target bucket and wire uninstall|remove into the bash, zsh and fish generators, mirroring how install is wired.

The bucket is the same ENGINES + TOOLS roster the dispatch resolves against (Object.hasOwn(ENGINES, target) || Object.hasOwn(TOOLS, target)), so every offered target is one uninstall will actually accept. Engine aliases are deliberately not offered, because that lookup does not resolve them, and install already behaves the same way. There is a test asserting that, so this cannot drift into offering targets that error.

--yes, -y and --dry-run complete after a target. --yes matters most: without it, removing a binary refuses and exits 1.

25 insertions, no deletions, no behaviour change outside completion.

Tests

New test/completion-uninstall.test.mjs, 13 tests.

8 are the bug and fail before / pass after: uninstall and remove in the top-level model; moshcode un<TAB> completing in real bash; every removable engine and tool offered; the alias completing the same set; the flags completing; zsh and fish covered too; and a copy of the dispatch-coverage guard so a future command added without completion fails next to this regression.

5 are controls that pass both ways and assert the opposite direction, so the fix cannot buy a green suite by over-offering or by disturbing what already worked: install completion byte-identical, no engine aliases offered, an unrelated command still completing nothing, uninstall not re-offering the roster outside the target position, and the generated bash still passing bash -n.

Fail-before was measured by reverting both source files with git checkout --: 8 fail / 5 pass unpatched, 13/13 patched.

Full suite: 560 tests / 1 fail → 573 tests / 0 fail. That one failure was the pre-existing completion.test.mjs one above, which this fixes. Baseline was measured by moving the new test file out rather than assumed.

Scoped out

uninstall is not in the moshscript vocabulary, so the cliVerbs split in help() is unaffected. I checked, because the comment there warns that a command missing from the roster "gets misfiled as a moshscript-only local verb" — that consequence does not apply here. The impact was confined to shell completion.