chore(build): build release binaries in ci

[sklarsa]

What this does

Reworks the Maven Central release into a single manually-triggered workflow that proves the release is good before doing anything irreversible. Native libraries are built and tested in CI (not committed by hand), and the git tag / Central publish only happen after the full test suite and the Central Portal validation have passed.

Release flow (abridged)

Trigger Release to Maven Central from the Actions tab, then approve the gated publish step when prompted:

resolve → build ×5 → verify → publish (gated) → open-bump-pr

1. resolve — infers the release version from the current -SNAPSHOT POM; fails fast if the tag or Central version already exists.
2. build ×5 — builds each platform's native lib (darwin-aarch64/x86-64, linux-x86-64/aarch64, windows-x86-64). The macOS and Linux libs are load-tested on their own runners; the cross-compiled Windows DLL is objdump-checked for a clean runtime-dependency list.
3. verify — bundles all five libs and runs the full test suite (exercises the linux-x86-64 lib directly). No credentials. This is the quality gate.
4. publish (gated by the maven-release environment) — after approval: signs and uploads a droppable VALIDATED deployment, pushes the release tag, then performs the single irreversible step of publishing the deployment via the Central Portal API. If anything fails, the tag is rolled back so reruns stay clean.
5. open-bump-pr — opens the next-development-version bump PR (post-release; merge it before the next release).

Key properties: validation happens before the tag is pushed, and the Central publish is the single irreversible step and runs last — a tag-push failure leaves nothing published and a clean rerun. The tag pins the exact verified tree. We never push commits to main (the snapshot bump is a PR, so main keeps its PR-only protection). The run does not block on Maven Central's asynchronous propagation (which can take minutes to an hour+).

Required one-time setup

• Tag ruleset bypass: add github-actions[bot] as a bypass actor on the org-wide restrict-tag-pushing ruleset, so the publish job can push (and roll back) the release tag. (Do not bypass the main branch ruleset — the snapshot bump goes through a PR.)
• maven-release environment: configure required reviewers (the human approval gate before any credentials are used).
• AWS release secret (MAVEN_RELEASE_AWS_SECRET_ARN) must define: MAVEN_GPG_PRIVATE_KEY, MAVEN_CENTRAL_USERNAME, MAVEN_CENTRAL_PASSWORD, and optionally MAVEN_GPG_PASSPHRASE (empty/absent for a passphrase-less key).

Full procedure: artifacts/release/README.md.

Follow-ups (not blocking)

• Pin the GraalVM JDK 25 download (currently /25/latest/) and the Windows jni_md.h (currently jdk25u@master) to exact builds + checksums — marked with TODO(pin) in the workflow.
• On the first real run, confirm the central-publishing-maven-plugin 0.9.0 log line matches the deploymentId: <uuid> capture, and that the GPG key imports cleanly from the AWS secret.

Evidence

Verified that the include-native-artifacts profile bundles staged binaries into the jar by mocking libquestdb.so with a test string, packaging, and confirming the jar contains the mocked version:

mvn -B -ntp -pl core clean
mkdir -p core/target/native-libs/io/questdb/client/bin/linux-x86-64
printf 'test-linux-x86-64\n' \
    > core/target/native-libs/io/questdb/client/bin/linux-x86-64/libquestdb.so
mvn -B -ntp -pl core package -Pinclude-native-artifacts -DskipTests

$ unzip -p core/target/questdb-client-1.3.2-SNAPSHOT.jar io/questdb/client/bin/linux-x86-64/libquestdb.so
test-linux-x86-64