fix(updates): report a plugin build installed beside the running one, never "up to date" on a failed check

A `claude plugin update` run from a terminal (or with only the Claude desktop
app open) unpacks the new build and starts nothing: no SessionStart fires, so
the dashboard kept running the old cache dir across reboots, and with the
forge unreachable the sidebar read "Up to date" (seen on a machine stuck at
1.8.10).

- pluginStatus asks supersededBy for its own root: a recorded sibling install
  sets `installed_not_running: {root, version}` and `update_available`, with
  no network needed
- the sidebar reads "<version> installed, not running"; the update modal keys
  on it, so Update now is offered even with no release tag or sha
- plugin-update-helper hands over to the recorded install first, the newest
  sibling dir only as a fallback
- a plugin install whose release lookup failed reads "Could not check for
  updates" instead of "Up to date"
- docs/PLUGINS.md: the case and the manual hand-over command

client/src/lib/types.ts

@@ -1352,6 +1352,10 @@ export interface UpdateStatusPayload {
    *  or `"http_<status>"`. Anything but `"ok"` means detection fell back to
    *  the commit-count comparison. */
   release_check?: string;
+  /** Plugin installs only: a newer build Claude Code has installed beside the
+   *  running one (`claude plugin update` from a terminal starts nothing), or
+   *  null. Sets `update_available`; "Update now" hands the server over to it. */
+  installed_not_running?: { root: string; version: string | null } | null;
   /** Tag of the newest published release, e.g. `"v1.5.0"`. null when
    *  `release_check !== "ok"`. */
   latest_release?: string | null;