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/model/modules/modules.db.js

@@ -17,6 +17,23 @@ const getOne = (id) => query(`SELECT ${COLS} FROM installed_modules WHERE id = ?
 // module must not silently disable it, and re-installing a disabled one must not
 // silently switch it back on. A brand-new row lands in `installed`, the transient
 // state the next restart resolves.
+// Provenance is COALESCEd, and that is the whole difference between this
+// working and not.
+//
+// `lifecycle.boot()` re-records every module it scanned with no source and no
+// sha256 — a directory placed on the volume by hand genuinely has neither, and
+// the boot has no way to know where one came from. With a plain
+// `source = VALUES(source)` that refresh overwrote both columns with NULL on
+// EVERY boot, so an admin-panel install's provenance survived exactly until the
+// restart that install asked for. Nothing could catch it before Phase 4: until
+// then no caller ever passed a non-null value, and lifecycle.js's comment
+// asserting that "recordInstalled leaves what it is not given" was a description
+// of an intention rather than of this statement.
+//
+// COALESCE makes that comment true: a value overwrites, a NULL leaves what is
+// there. The cost is that re-placing a DIFFERENT bundle by hand over a row that
+// was once installed from a URL keeps the old provenance — which is wrong but
+// stale, and strictly better than the alternative, which was wrong and blank.
 const upsert = ({ id, name, version, source, sha256 }) =>
   query(
     `INSERT INTO installed_modules (id, name, version, source, sha256, state)
@@ -24,8 +41,8 @@ const upsert = ({ id, name, version, source, sha256 }) =>
      ON DUPLICATE KEY UPDATE
        name    = VALUES(name),
        version = VALUES(version),
-       source  = VALUES(source),
-       sha256  = VALUES(sha256)`,
+       source  = COALESCE(VALUES(source), source),
+       sha256  = COALESCE(VALUES(sha256), sha256)`,
     [id, name, version, source ?? null, sha256 ?? null],
   )