plugins: enabling pulls first, so a plugin off for a week comes back current

A disabled plugin keeps its directory, and the directory is what the next start runs. The longer it
stays off the more certainly it is stale, and enabling would quietly run whatever was current on the
day it was switched off — with every step reporting success, which is exactly how the jellyfin
install on alpha re-applied a two-day-old checkout.

Deleting no longer has that problem, since it takes the directory with it and installing is always a
fresh clone. That left disable/enable as the one remaining way to run old code without being told.

The pull is best-effort and the enable is not. `updatePlugin` returns ok:false when a pull is
refused, and it is refused for reasons that say nothing about whether the plugin can run: a dirty
working tree — every plugin directory on this machine is one — an unreachable forge, or a directory
copied in rather than cloned. Enable is the reversible half of a pair with disable, and a switch that
will not turn back on because a network is down is worse than one running last week's code. So the
refresh reports which of those happened and the enable proceeds regardless; a re-apply that fails
falls back to the code already on disk, which was running before it was disabled.

Tested by the refusal path rather than the happy one: a directory that is not a checkout comes back
having reported "not refreshed", and the error that surfaces is about not being installed rather than
about git — which is only possible if the refusal was stepped past instead of returned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/plugins/update.test.ts

@@ -2,7 +2,7 @@ import { describe, expect, test, afterAll } from 'bun:test';
 import { mkdirSync, rmSync, writeFileSync } from 'node:fs';
 import { join } from 'node:path';
 import { PLUGINS_DIR } from './discover';
-import { pullPlugin } from './update';
+import { pullPlugin, enablePlugin } from './update';
 
 // The REFUSALS are what this test is for. A pull that works is easy to believe; a pull that quietly
 // discarded somebody's uncommitted work is the failure that matters, and every plugin directory on a
@@ -53,3 +53,27 @@ describe('pullPlugin refuses rather than guesses', () => {
     }
   });
 });
+
+// ── Enabling must survive a refusal to pull ──
+//
+// `enablePlugin` refreshes the checkout before turning a plugin on, so that a plugin which sat disabled
+// for a week does not come back running the code it was switched off with. The risk in that is obvious:
+// the pull is refused for reasons that say nothing about whether the plugin can run — a dirty tree, an
+// unreachable forge, a directory that was copied in rather than cloned — and enabling is meant to be the
+// reversible half of a pair with disable.
+//
+// So this asserts the pull refusal is REPORTED and then stepped past. The enable itself still fails here,
+// because a scratch directory has no install row — and that is the point: the failure that comes back is
+// about being installed, not about git, which is only possible if the refusal did not short-circuit.
+describe('enablePlugin steps past a pull it cannot do', () => {
+  test('a directory that is not a git checkout still reaches the enable', async () => {
+    // Named without the word "git" in it, so the last assertion below is about the error and not about
+    // the fixture's own name.
+    scratch('test-enable-plain');
+    const r = await enablePlugin('test-enable-plain');
+
+    expect(r.steps.some((s) => s.includes('not refreshed') && s.includes('not a git checkout'))).toBe(true);
+    expect(r.error).toContain('not installed');
+    expect(r.error).not.toContain('git');
+  });
+});