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, and the git tag / Central publish only happen after the full test suite and the Central Portal validation have passed.

This update also fixes the tag-ruleset bypass model: GitHub does not expose the built-in GITHUB_TOKEN identity (github-actions[bot]) as a usable ruleset bypass actor. The publish job now mints a token from a dedicated Maven release GitHub App, and that app is the actor that must be added to the org-wide restrict-tag-pushing bypass list.

Release flow (abridged)

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

resolve -> build x5 -> 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 x5 - builds each platform 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. No credentials. This is the quality gate.
4. publish - gated by the maven-release environment. After approval, it signs and uploads a droppable VALIDATED deployment, pushes the release tag using the Maven release GitHub App token, then performs the single irreversible Central Portal publish step. If anything fails before publish is accepted, the tag is rolled back so reruns stay clean.
5. open-bump-pr - opens the next-development-version bump PR. 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 asynchronous propagation.

Required one-time setup

• Tag ruleset bypass: create a dedicated Maven release GitHub App, install it on this repository with Contents: read/write, and add that app as a bypass actor on the org-wide restrict-tag-pushing ruleset. Do not try to add github-actions[bot]; GitHub does not offer it as a usable bypass actor here.
• App credentials: set repository variable MAVEN_RELEASE_GITHUB_APP_CLIENT_ID to the app client ID, and set MAVEN_RELEASE_GITHUB_APP_PRIVATE_KEY as a maven-release environment secret.
• maven-release environment: configure required reviewers. This is the human approval gate before any release 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.

Full procedure: artifacts/release/README.md.

Follow-ups (not blocking)

• Pin the GraalVM JDK 25 download and the Windows jni_md.h to exact builds + checksums. Both are marked with TODO(pin) in the workflow.
• On the first real run, confirm the central-publishing-maven-plugin 0.9.0 log line still 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