feat(windows): make libpq and abseil-cpp build for a mingw host

[dlipicar]

Two nixpkgs packages that Logos modules declare in metadata.json
nix.packages.runtime but that do not build for a mingw host. Both fixed here
rather than in each consumer, alongside the existing cli11 / glib / sqlite
/ libwebp entries.

The common cause

nixpkgs builds mingw-w64 against mcfgthread, so pthread.h and
libpthread.a do not exist anywhere in the default cross closure. Anything
carrying an unconditional POSIX-threads assumption fails, and it fails late —
during compilation of a transitive dependency, far from whatever declared it.

This is the same hole that has already produced four other unrelated-looking
failures during the Windows port: libpq's pthread_barrier_wait.c, Rust's
x86_64-pc-windows-gnu std wanting -l:libpthread.a, lsquic's
clock_gettime64, and nim-boringssl. Adding windows.pthreads to the offending
package's buildInputs is the whole fix in each case.

abseil-cpp

absl/base/internal/thread_identity.cc:18:10: fatal error: pthread.h: No such file or directory
   18 | #include <pthread.h>

One line. Verified: builds clean for x86_64-w64-mingw32 with the fix, producing
libabsl_*.dll.a.

libpq

Four unrelated obstacles, none of them individually interesting:

• curlSupport = false — postgres 18 links libcurl for its OAuth device
  flow, and curl cross to mingw drags in ngtcp2 → nghttp3, whose examples
  #include <arpa/inet.h> and fail. Nothing in Logos uses OAuth auth.
• drop make-shell-wrapper-hook — makeWrapper resolves to a
  host-platform bash, and mingw bash does not build. libpq never calls
  wrapProgram; the hook is vestigial.
• windows.pthreads — the mcfgthread gap above.
• separateDebugInfo = false — that hook runs objcopy --only-keep-debug,
  which is the ELF split.

Note this is the client library only. Full postgresql (the server) has no
mingw build and is deliberately not made available — a module that wants
postgres should declare libpq, which is all it ever links or dlopens anyway
(see logos-co/logos-delivery-module#85, which corrects exactly that
declaration).

Verified: libpq.dll builds, loads on real Windows 10.0.26200, and
PQconnectdb/PQexec/PQfinish/PQlibVersion resolve. Its import table is
fully Nix-tracked — Windows system DLLs plus the two OpenSSL DLLs, which
win-dll-link.sh already stages.

Why these two, now

logos-delivery-module needs libpq; logos-chat-ui declares abseil-cpp.
Neither could be expressed per-platform in metadata.json —
parseMetadata.nix produces one flat list with no host gating — so the fix has
to live in the package set.

A note for reviewers

Both entries are narrow overrideAttrs on top of upstream. If this pattern keeps
recurring (this is the fifth instance), the alternative worth considering is
making the whole cross set use a pthreads-providing thread model rather than
mcfgthread, which would fix the class instead of the instances. That is a much
larger change — it rebuilds the entire Windows closure — so I have not attempted
it here, but it may be the right long-term answer.

🤖 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.