fix: v2.3.1 — correct version, say why a plugin update failed, gitignored files in Files

- v2.3.0's tree reported 2.2.1, so every install saw an update forever;
  package.json, the lockfile, openapi.yaml, the CLAUDE.md marker and the
  snapshot now read 2.3.1
- A failed plugin-update step records the tail of the command's stdout and
  stderr plus its exit code or signal (failureText); plugin-bootstrap.js
  prints its refusal on stdout, which the verdict used to drop. Update all
  uses the same text
- updates.test.js never applies an update: it skips when the checkout is
  behind a release (apply ran npm run setup and pruned dev dependencies)
- Files tree lists gitignored files and folders, named in orange
  (addIgnored in git-diff.js); change-tree rows indent in whole steps

server/__tests__/updates.test.js

@@ -91,7 +91,17 @@ describe("POST /api/updates/check", () => {
 });
 
 describe("POST /api/updates/apply", () => {
-  it("declines with a reason instead of pulling/restarting when there is nothing to apply", async () => {
+  it("declines with a reason instead of pulling/restarting when there is nothing to apply", async (t) => {
+    // Never let this test APPLY anything. When this checkout really is behind
+    // a release (or reports a version older than the newest tag), the route
+    // fast-forwards the repo, runs `npm run setup` — which under the shell's
+    // NODE_ENV=production prunes every dev dependency — and SIGTERMs the
+    // process to restart it. That happened once; ask first and stand down.
+    const status = await httpFetch("/api/updates/status");
+    if (status.body.update_available) {
+      t.skip(`this checkout is behind ${status.body.latest_release}; not applying it in a test`);
+      return;
+    }
     // The test repo checkout has no update pending (or isn't fast-forwardable
     // from a bare test run), so this exercises the decline path only — it must
     // never touch the working tree or process in a test run.