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 + smoke-loads the native lib for each platform (darwin-aarch64/x86-64, linux-x86-64/aarch64, windows-x86-64).
3. verify — bundles all five libs and runs the full test suite. No credentials. This is the quality gate. (The suite runs on Linux, so it exercises the linux-x86-64 lib directly; the other four are smoke-loaded on their own platform in the build step.)
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.
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 — so 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 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.
• Confirm the central-publishing-maven-plugin 0.9.0 log line matches the deploymentId: <uuid> capture on the first real run.

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