fix(modules): three defects a real install exposed (phase 4, slice 1)

Standing the slice-2 screen up against a live server and installing the
published module-uo v0.3.0 through it found three things, none of which any
unit test in this repo could have caught. Two of them are older than this
phase.

1. The boot refresh nulled every install's provenance
--------------------------------------------------------
`installed_modules.source` and `.sha256` exist so the admin panel can say
where a module came from. They never survived a restart.

`lifecycle.boot()` re-records every scanned module with no source and no
sha256 -- correctly, because a scan finds a directory and never where it came
from -- and `upsert` assigned both columns unconditionally. So an install's
provenance lasted exactly until the restart that install asked for, and the
screen then described a module installed from a URL as "placed on the volume
by hand". Verified live: install, restart, provenance gone.

Nothing could have caught it before now. Phase 4 wrote the first non-null
value these columns had ever had, so lifecycle.js's comment asserting that
"recordInstalled leaves what it is not given" described an intention rather
than the statement below it -- and modules.model.test.js's fake reproduced
the defect faithfully, assigning unconditionally just like the SQL.

Fixed with COALESCE(VALUES(col), col): a value overwrites, a NULL leaves what
is there. The fake now matches, and two tests pin both directions -- a boot
refresh must not wipe it, and a re-install from a new URL must still replace
it, or the column would become write-once and an upgrade would for ever show
where the first version came from.

2. The restart killed the server on Windows instead of stopping it
------------------------------------------------------------------
The route called `process.kill(process.pid, 'SIGTERM')` to reach server.js's
graceful-shutdown handler. That works on Linux. **Windows has no POSIX
signals, and Node documents SIGTERM there as unconditional termination of the
target process** -- so on a Windows host the restart killed the server
outright: no module onShutdown, no listener close, no pool close, no log
flush. Observed exactly that: the process was gone and the shutdown handler
had logged nothing at all.

`process.on('SIGTERM', ...)` is an ordinary EventEmitter listener, so
`process.emit('SIGTERM')` reaches the same handler on every platform without
involving the OS. One shutdown path, still; it just gets there by an event.

Deployment is Linux containers and would never have shown this. Development
is not, and neither is the smoke that found it.

The test was worse than useless: it stubbed `process.kill` and asserted it
had been called with SIGTERM, which is precisely the call whose MEANING
differs by platform. It now waits for the SIGTERM EVENT -- what server.js is
actually subscribed to -- so a pass here means the handler would run.

3. `present()` did not publish the running version
--------------------------------------------------
An upgrade writes new files and a new row while the old code stays loaded, so
the row's version is a promise about the next boot rather than a description
of this one. Adds `liveVersion` from the loader beside `liveState`, so the
screen can tell the two apart instead of reporting the new version as running.

723 server tests (+2), manifest and OpenAPI both unchanged.

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

server/src/router/v1/admin/modules.controller.js

@@ -85,6 +85,11 @@ function present(row, live, onVolume) {
     startedAt: row ? row.startedAt : null,
     // What is actually mounted in this process, and what it is answering.
     liveState: live ? live.state : null,
+    // The version RUNNING, which is not always the version installed: an upgrade
+    // writes new files and a new row while the old code stays loaded until the
+    // restart. Without this the screen would report the new version as
+    // "Running", which is the same lie in a different place.
+    liveVersion: live ? live.version : null,
     capabilities: live ? live.capabilities : [],
     // What is on the volume.
     onVolume,
@@ -349,11 +354,24 @@ async function setSources(req, res) {
 // "with no shell access to the box" — which a banner saying "please restart your
 // container" does not deliver.
 //
-// It raises SIGTERM against its own process rather than calling the shutdown
-// path directly. server.js already has a handler that stops the modules, the
-// workers and the listeners in the right order and closes the pool and the log
-// file before exiting 0; reaching that through the signal means there is exactly
-// one graceful-shutdown path and this route cannot drift from it.
+// It reaches server.js's existing SIGTERM handler rather than doing the work
+// itself: that handler stops the modules, the workers and the listeners in the
+// right order and closes the pool and the log file before exiting 0, and going
+// through it means there is exactly one graceful-shutdown path that this route
+// cannot drift from.
+//
+// It gets there by EMITTING the event, not by signalling the process, and that
+// is not a detail. `process.kill(process.pid, 'SIGTERM')` is what this did
+// first, and it works on Linux — but **Windows has no POSIX signals, and Node
+// documents SIGTERM there as unconditional termination of the target process**.
+// So on a Windows host the restart killed the server outright: no module
+// `onShutdown`, no pool close, no log flush. Verified by running it — the
+// process was gone and the shutdown handler had logged nothing.
+//
+// `process.on('SIGTERM', …)` is an ordinary EventEmitter listener, so
+// `process.emit('SIGTERM')` invokes exactly the same handler on every platform
+// without involving the OS at all. Deployment is Linux containers and would
+// never have shown this; development is not.
 //
 // What brings the process BACK is the supervisor, not this. The shipped
 // docker-compose.yml declares `restart: unless-stopped` on `app`, which restarts
@@ -372,7 +390,7 @@ function restart(req, res) {
     .finally(() => {
       // A beat, so the 202 is on the wire. `unref` so this timer is not itself
       // something keeping the process alive.
-      setTimeout(() => process.kill(process.pid, 'SIGTERM'), 250).unref()
+      setTimeout(() => process.emit('SIGTERM'), 250).unref()
     })
 }