ci: run postgres fixtures on linux + macos

[cs01]

What you get

The 5 postgres fixtures shipped in #512 now actually run in CI. Before this PR they were @test-skip, so any regression in lib/postgres.ts or pg-bridge.c would land silently on main and only get caught when someone ran a fixture by hand. Now both the linux and macOS jobs spin up a real postgres and exercise the full path: connect, parameterized query, SELECT, type coercion, Pool lazy-connect.

Why

This was the highest-leverage cleanup from PR #512's punch list. Without CI coverage we had no actual regression net for postgres; with it, the next four follow-ups (null detection, reconnect-on-drop, date type, etc.) can be developed and reviewed safely. It also unblocks any future stdlib module that wants the same "test against a real service" pattern.

How

• Linux job (build-linux-glibc): services: postgres:16 container with POSTGRES_USER=postgres POSTGRES_PASSWORD=test POSTGRES_DB=chadtest matching the fixture conninfo, plus libpq-dev in apt and PG_TESTS_ENABLED=1 at job env.
• macOS job (build-macos): brew install libpq postgresql@16, brew services start postgresql@16, provision the postgres user/password/db, PG_TESTS_ENABLED=1 at job env.
• @test-requires-env: VAR: new test-discovery annotation that skips a fixture unless the named env var is set and non-empty. Replaces @test-skip on the 5 postgres fixtures. The discovery filter happens at the test-runner level, so platforms or developer machines without postgres see the fixtures cleanly skipped instead of failing or polluting unrelated runs.

Side fix (separate gap from #512)

src/chad-native.ts never called registerStdlib("postgres.ts", ...). The native compiler (.build/chad) embeds stdlib files at build time via ChadScript.embedFile, and postgres.ts was missing from the registry — so any user trying to import { Pool } from "chadscript/postgres" against the native compiler got stdlib module not found: postgres.ts. All my prior verification went through node dist/chad-node.js (which reads lib/*.ts from disk), so the embedded-stdlib path was untested. Now registered alongside the other lib/ modules. Without this fix .build/chad users couldn't have used chadscript/postgres at all — that's a real user-facing bug from #512 caught by this PR's stronger CI coverage.

Test plan

• PG_TESTS_ENABLED=1 npm run verify (full, with stage 2) green locally against podman postgres:16 — all 5 fixtures pass
• npm run verify:quick without PG_TESTS_ENABLED — fixtures cleanly skipped, no regressions
• CI green on both build-linux-glibc (service container) and build-macos (brew postgres)
• Post-merge: confirm CI catches a synthetic regression by reverting the bridge and watching CI fail (manual smoke once merged)

🤖 Generated with Claude Code

[github-actions]

Benchmark Results (Linux x86-64)

Benchmark	C	ChadScript	Go	Node	Place
Binary Trees	1.458s	1.195s	2.678s	1.239s	🥇
Cold Start	1.0ms	0.9ms	1.2ms	28.2ms	🥇
Fibonacci	0.910s	0.802s	1.732s	3.373s	🥇
File I/O	0.087s	0.094s	0.086s	0.164s	🥉
JSON Parse/Stringify	0.004s	0.005s	0.016s	0.015s	🥈
Matrix Multiply	0.499s	0.741s	0.781s	0.457s	🥉
Monte Carlo Pi	0.439s	0.440s	0.458s	2.600s	🥈
N-Body Simulation	1.756s	2.253s	2.293s	2.381s	🥈
Quicksort	0.246s	0.284s	0.242s	0.298s	🥉
SQLite	0.323s	0.340s	—	0.406s	🥈
Sieve of Eratosthenes	0.014s	0.027s	0.020s	0.042s	🥉
String Manipulation	0.008s	0.017s	0.015s	0.039s	🥉

CLI Tool Benchmarks

Benchmark	ChadScript	grep	node	xxd	Place
Hex Dump	0.436s	—	0.948s	0.139s	🥈
Recursive Grep	0.021s	0.011s	0.102s	—	🥈