fix: make delivery_module cross-compile for Windows

[dlipicar]

Two portability defects that stop delivery_module cross-compiling for
x86_64-w64-mingw32. Both are invisible on Linux/macOS, and neither is
Windows-specific in nature — one is arguably a correctness improvement on
every platform.

1. nix.packages.runtime declared postgresql, not libpq

postgresql is the server, which has no mingw build in nixpkgs, so a
Windows evaluation hard-failed on meta.platforms before anything compiled:

error: Refusing to evaluate package 'postgresql-17.10' ... because it is not
       available on the requested hostPlatform:
         hostPlatform.system = "x86_64-windows"

The module never links or loads the server — it dlopens libpq, which is
what postInstall already goes looking for via pkg-config --variable=libdir libpq. Declaring libpq directly is narrower and more correct everywhere, and
drops the entire server from the closure.

2. currentTimestampNs() used POSIX clock_gettime

mingw declares neither clock_gettime nor CLOCK_REALTIME:

src/delivery_module_plugin.cpp:38:19: error: 'CLOCK_REALTIME' was not declared in this scope
src/delivery_module_plugin.cpp:38:5:  error: 'clock_gettime' was not declared in this scope

std::chrono::system_clock is the portable spelling of the same wall-clock
reading, needs no platform branch, and the translation unit is already built at
-std=c++20. I swept the rest of src/ for other POSIX-isms (gettimeofday,
<unistd.h>, <sys/*>, /tmp, $HOME) — clean.

Verification

Cross-built for x86_64-w64-mingw32 and run on real Windows (10.0.26200,
x86_64). delivery_module_plugin.dll is a PE32+ DLL exporting
qt_plugin_instance / qt_plugin_query_metadata_v2, loads into the
logoscore daemon, and dispatches:

$ logoscore.exe list-modules
[{"name":"delivery_module","status":"not_loaded","version":"0.1.3"}]

$ logoscore.exe load-module delivery_module
{"module":"delivery_module","status":"ok","version":"0.1.3"}

$ logoscore.exe call delivery_module version
{"method":"version","module":"delivery_module",
 "result":"1.1.0 (liblogosdelivery version unknown, context not initialized)",
 "status":"ok"}

Daemon log confirms the module's own C++ ran:

[info] [logos] Module loaded: delivery_module
[info] [logos] [delivery_module] DeliveryModuleImpl: Initializing...
[info] [logos] [delivery_module] DeliveryModuleImpl: Initialized successfully

Linux and macOS are unaffected: the libpq swap resolves to the same
pkg-config lookup the module already performed, and std::chrono compiles
identically.

Dependencies

Getting here also needed fixes outside this repo, which are not required for
this PR to be correct but are required to reproduce the Windows build:

• logos-delivery — Windows cross support, plus an import library so consumers
  can link the DLL rather than silently falling back to the static archive
  (liblogosdelivery.a), and FFI C bindings are never generated: genBindings() writes nothing without --experimental:vmopsDanger logos-messaging/logos-delivery#4121 (genBindings()
  emits nothing without --experimental:vmopsDanger).
• logos-module-builder / logos-plugin-qt — stage an external library's
  runtime DLL from <drv>/bin, and implement the previously-inert include
  metadata field so dlopened runtime deps such as libpq.dll land beside the
  plugin (nothing else can find them: the Windows DLL walk is import-table
  driven).

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.