mssql: its handlers, tools and provisioner run in the node's runtime, through the driver in its bundle (hq ADR 0198)

The mesh-mssql container goes with its Dockerfile (and the sqlcmd it fetched), build bases and bus credential. The client speaks TDS through the mssql driver its package.json names, inlined into the bundle by the builder (ADR 0198 §4): one session per call as one sqlcmd invocation was, FOR JSON rendering rows exactly as before, the consumer's password checked as a bound parameter. A caller's statement still runs only as the reader login (issue 193); the one-line rule and -x guarded against sqlcmd's own commands and variable substitution, which no longer stand between the caller and the server. The server is reached on loopback at the port the machine published (${port:1433}). The reader test drives a fake session in place of a fake sqlcmd.

modules/mssql/index.ts

@@ -1,9 +1,9 @@
-// mssql's events entrypoint, loaded by the per-node tool host (the provisioner container runs
-// ./provisioner separately). The database lifecycle events are EMITTED from the provisioner, where
+// mssql's events entrypoint, launched by the node's runtime beside its tools and provisioner
+// (novox/hq ADR 0198). The database lifecycle events are EMITTED from the provisioner, where
 // the lifecycle actually happens (novox/hq ADR 0041/0042):
 //   module.mssql.database.provisioned    — a consumer's database + login/user was created
 //   module.mssql.database.deprovisioned  — that database was removed
-// Here in the tool host we react to them, keeping a lightweight audit trail of who was granted a
+// Here in the runtime we react to them, keeping a lightweight audit trail of who was granted a
 // database and who lost one — observability the provider itself is best placed to log.
 
 import { on } from "@novox/mesh-sdk/events";