feat!: Publish releases to Maven Central, starting with version 1.0.0.

[goloroden]

Turns on publishing to Maven Central in the release workflow, and makes the first published version 1.0.0.

What changes

• Release workflow: The publish step, commented out so far, is active. On every new version it uploads all three artifacts (io.thenativeweb:eventsourcingdb, eventsourcingdb-testcontainers, eventsourcingdb-spring-boot-starter) to Maven Central, signed with the release key.
• Upload, not release: It runs publishToMavenCentral, which uploads the deployment without releasing it. The deployment waits in the Central Portal to be checked and released by hand, since what is released on Maven Central can never be removed. Once the first release went through, a follow-up switches to publishAndReleaseToMavenCentral.
• Version 1.0.0: The commit is a feat!:, so get-next-version moves from 0.8.0 to 1.0.0, the way the other client SDKs reached 1.0.0.

Prerequisites, all in place

• The namespace io.thenativeweb is verified on central.sonatype.com, through a DNS TXT record on thenativeweb.io.
• The signing key the native web GmbH <hello@thenativeweb.io> (RSA 4096, fingerprint 2B624590673BBCC8B8135242C5796288E8FDBC87, valid until October 7, 2028) is on keyserver.ubuntu.com and keys.openpgp.org.
• The secrets TOKEN_GITHUB_TO_MAVEN_CENTRAL_USERNAME, TOKEN_GITHUB_TO_MAVEN_CENTRAL_PASSWORD, KEY_GITHUB_TO_MAVEN_CENTRAL_SIGNING and KEY_GITHUB_TO_MAVEN_CENTRAL_SIGNING_PASSWORD are set.
• The repository is public.

After merging

1. The release workflow tags v1.0.0 and uploads the deployment.
2. Check it in the Central Portal under "Deployments": all three artifacts with jar, sources, Javadoc, POM and signatures. Then release it.
3. If the upload fails, e.g. because of a wrong secret, the tag v1.0.0 stays, and the next release gets the next version.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hc2MPSLu7HDHTm8HiBsrDz