Feature: di.heartbeat

[Olly99999]

di.heartbeat
Extracts TorQ's code/common/heartbeat.q into a standalone kdb-x module (Tier-1, no hard module dependencies).

What it does. Lets a process publish a periodic heartbeat over pub/sub, and lets a monitoring process collect those beats and detect when a process has gone silent — escalating it to warning then error after configurable grace periods. This catches a process that is alive but stuck (blocked, deadlocked, GC-thrashing), which a plain "is the connection open?" check cannot.

Two sides:

Publish — publishheartbeat emits a one-row beat (type, name, counter, pid/host/port) on a timer.
Monitor — storeheartbeat records incoming beats (latest per process, clearing prior alerts); checkheartbeat flags any that have aged past their grace period and fires onwarning/onerror callbacks. Alerts are edge-triggered (fire once per transition) and re-arm automatically when a process beats again.
Dependency injection. All runtime dependencies are injected via init[config;deps] as dictionaries of functions, per the injectable-dependency guidance:

log, timer, pubsub — always required
servers, handlers — required only when running as a monitor (subenabled)
Missing required deps error immediately with a clear message rather than silently degrading. The module keeps its own clock (cp/setcp) so it doesn't depend on the timer exposing a getter, and overriding it makes the staleness logic deterministic for tests.

Conventions. No \d namespaces — module-local state via .z.m. No direct .z.* handler assignment — the .z.pc cleanup goes through the injected handlers dependency. Config via dictionary, not @[value;…]. FinSpace code stripped (none present).

Files: init.q (entry point + exports + version), heartbeat.q (implementation), deps.q (empty — all deps injected), heartbeat.md (docs), test.csv (38 k4unit tests, all passing).

Status. Unit-tested (38/38) and manually integration-tested against the real di.timer and di.pubsub — verified beats publishing on schedule and a killed publisher being escalated to error end-to-end. Known follow-ups: init is not yet idempotent (re-running collides on timer job ids); the servers/handlers auto-discovery path awaits the real di.servers/di.handlers modules.