plugin add/remove: nothing records what an install created, so the undo and the uninstall both guess

Start with the plugin add and plugin remove paths that write matbot.yaml, the root package.json key, .plugins/node_modules/<name> and .plugins/.restore/, and with readDependencyNames, which the payload says both paths share. Reproduce one add then remove on the npm route and list what remains under .plugins/. Done when a per-plugin install record drives both the undo and remove, and add then remove leaves nothing add created. Open PR #103 already targets this, so coordinate with it before starting.

Summary

plugin add creates things in up to six places depending on the route: a package.json key, node_modules, .plugins/<host>/…, a .plugins/node_modules/<name> self-link, dependencies installed into a cache directory or a local checkout, and .plugins/.restore/. Nothing records which of them a given install created. So remove, and the undo of an add that then disowns the plugin, both infer it from the state they find. Each fix to one inference has broken the other, and a live run shows remove leaving most of it behind.

These should be fixed together. They are two halves of one question: what did this install create, and who takes it back out?

Already known

The gap #90 left. On the npm route, an add that then disowns the plugin keeps the install. That happens on a duplicate name, an incompatible runtime, or "not a plugin". On a duplicate name config is never written, so remove has no entry to offer the uninstall against.

Two regressions in the attempted fix. The fix is in PR #93's commits (6d56bd1, 1f42280, never merged; #93 is closed in favour of this issue):

1. readDependencyNames was widened to devDependencies and peerDependencies for the undo's before-snapshot. remove shares it, so plugin remove @x/foo now offers to pm remove a package the project declares only as a peer or dev dependency, deleting the project's own declaration.
2. A new pre-install name-clash guard refuses plugin add [email protected] when foo is loaded. That removes the only in-tool way to change an npm plugin's version; before, the version changed on disk and a reload picked it up despite the clash error.

Found by a live add → reload → remove run

The run used @matatbread/matbot-email from github, a local path, npm and http. All four routes installed, reloaded and worked. remove cleans matbot.yaml and, for npm, the root package.json key and node_modules link, but leaves:

3. The self-link .plugins/node_modules/@matatbread/matbot-email. It survives remove, so a removed plugin is still resolvable by bare name. It was repointed by whichever route installed last, and was left dangling at the end.
4. The cached source and its installed dependencies. .plugins/raw.githubusercontent.com/MatAtBread/matbot-email/ kept HEAD/, main/ and refs/heads/main/, each with src/ and a full node_modules (imapflow, mailparser, nodemailer, …). Each spelling of the same repo is a separate cache directory that is never reclaimed; main/ held an older revision.
5. Empty .plugins/.restore/… directories left behind after discardRestore.
6. The host's pnpm-lock.yaml rewritten. After the npm cycle the lockfile had lost its catalogs: block, while package.json was back as it was. The node_modules/.pnpm entries also remain, though pruning those is arguably pnpm's job.
7. Local route: installing dependencies writes node_modules and package-lock.json into the user's checkout. That is by design, but remove never mentions it.

Suggested direction

Use the same shape as the #89 fix (#97): state it instead of deriving it. add would write an install record per plugin, saying which route it took, the dependency key it introduced into package.json (if any), the cache root, the self-link, and the dependency directories and lockfile it created. Both the undo-on-disown and remove would replay that record and act on nothing else, with nothing inferred from the specifier or a manifest diff. Changing an installed plugin's version would become an explicit operation rather than a side effect of the clash path.

Done when

• For every route, add → remove leaves nothing that add created, unless remove was told to keep it.
• A failed or disowned add leaves nothing behind.
• Neither path ever touches a dependency that add did not introduce.
• plugin add foo@<version> on a loaded foo has a defined, documented behaviour.