feat(infra): automaticRelease=false, snapshot workflow, proper resolveAndLockAll

[MichielDean]

Follow-up to #3. Addresses issue #8 — three items from bokelley's post-merge review.

What changed

Area	Change
automaticRelease = false	Staged bundles wait for human review in Central Portal UI before going live. Flip back to true after first clean v0.3 publish — tracked in #10.
publish-snapshot.yml	New workflow on push to main. Reads project version via ./gradlew properties; skips if not -SNAPSHOT. vanniktech routes -SNAPSHOT versions to Central Portal's snapshot repo automatically. GPG secret names aligned with release.yml (GPG_SECRET_KEY / GPG_KEY_ID / GPG_PASSPHRASE). Added concurrency group (cancel-in-progress: false) to prevent racing uploads of the same SNAPSHOT coordinates. cosign-installer step moved after version check and guarded with the same if: condition — only installs when the publish step will actually run.
resolveAndLockAll (per Gradle docs)	Previous updateLocks used dependsOn(:X:dependencies) which only walks the dependency report. Correct Gradle pattern: configurations.filter { it.isCanBeResolved }.forEach { it.resolve() } within each project's own context. Registered in adcp.java-base-conventions so each subproject owns it (Gradle 9 disallows cross-project config resolution from a root doLast). Root updateLocks aggregates :${name}:resolveAndLockAll.
Documentation fix	build.gradle.kts and CONTRIBUTING.md incorrectly claimed settings-gradle.lockfile is auto-rewritten by updateLocks --write-locks. Testing confirms this is false. Corrected: the settings lockfile must be regenerated separately with rm settings-gradle.lockfile && ./gradlew help --write-locks.
release.yml task fix	Changed from publishAndReleaseToMavenCentral to publishToMavenCentral — the former always auto-releases regardless of the automaticRelease flag; only the latter respects it.

Test plan

• ./gradlew clean build -PskipCosign=true — BUILD SUCCESSFUL
• ./gradlew updateLocks --write-locks -q && git diff --exit-code — no drift
• ./gradlew updateLocks (without --write-locks) — fails fast with clear fix-command message
• Corrupt a lockfile → updateLocks --write-locks repairs it
• Corrupt settings-gradle.lockfile → updateLocks --write-locks does NOT repair it (by design, documented correctly now)
• Both workflows use identical GPG secret names: GPG_SECRET_KEY / GPG_KEY_ID / GPG_PASSPHRASE

Closes #8

[bokelley]

Tested locally with JDK 21: updateLocks --write-locks produces no drift, and updateLocks without the flag now fails fast with must be run with the --write-locks flag per module. The Gradle 9 isolation issue is correctly addressed by the per-project resolveAndLockAll pattern.

Blocker — GPG secret name mismatch with release.yml

release.yml uses:

GPG_SECRET_KEY      → signingInMemoryKey
GPG_KEY_ID          → signingInMemoryKeyId
GPG_PASSPHRASE      → signingInMemoryKeyPassword

publish-snapshot.yml (new) uses:

GPG_SIGNING_KEY            → signingInMemoryKey
GPG_SIGNING_KEY_ID         → signingInMemoryKeyId
GPG_SIGNING_KEY_PASSWORD   → signingInMemoryKeyPassword

With signAllPublications() still in adcp.publishing-conventions.gradle.kts, the snapshot job will resolve those secrets to empty strings (GitHub masks the lookup, doesn't error) and signing will fail at runtime. Either rename to match release.yml, or update both workflows to one canonical set — but don't ship them divergent.

Nits (non-blocking)

1. No concurrency: group on publish-snapshot.yml. Two pushes to main in quick succession will race two Central Portal uploads of the same SNAPSHOT coordinates. Suggest:

   concurrency:
     group: publish-snapshot
     cancel-in-progress: false

   cancel-in-progress: false is safer — you don't want a half-uploaded artifact from a cancelled job.

2. cosign-installer runs unconditionally, even when the version isn't a SNAPSHOT and the publish step is skipped. Minor; could move under the same if: as the publish step.

3. automaticRelease = false flip — exactly what was asked for. Worth filing a quick follow-up issue (flip back to true after first clean v0.3 publish) so the manual step doesn't outlive its usefulness.

Looks good

• resolveAndLockAll registered in java-base-conventions (applied transitively to every subproject via java-library-conventions / kotlin-library-conventions / schema-codegen-conventions).
• require(...isWriteDependencyLocks) guard with clear error message.
• notCompatibleWithConfigurationCache(...) declaration is correct since the task resolves configurations at execution time.
• CI step simplification (--no-configuration-cache removed) is appropriate now that the task itself declares incompatibility.
• CONTRIBUTING.md doc update accurately describes the new behavior.

Once the secret names are aligned with release.yml (and ideally the concurrency group added), this is ready to merge.

[bokelley]

All three items from the prior review are addressed:

• GPG secret names now match release.yml (GPG_SECRET_KEY / GPG_KEY_ID / GPG_PASSPHRASE). ✅
• Concurrency group added with cancel-in-progress: false. ✅
• cosign-installer step is now scoped under if: steps.version-check.outputs.is_snapshot == 'true'. ✅

Bonus improvements:

• release.yml switched from publishAndReleaseToMavenCentral to publishToMavenCentral, which is the right pairing with automaticRelease = false and includes a clear comment about the migration back to publishAndReleaseToMavenCentral once we've had a clean publish or two. This tackles the follow-up I'd flagged.
• The settings-gradle.lockfile docs are now honest: updateLocks doesn't regenerate it, and the manual rm settings-gradle.lockfile && ./gradlew help --write-locks workaround is documented. CI's drift check on the file will catch any divergence. Pragmatic given the Gradle quirk.

Verified locally one more time: ./gradlew updateLocks --write-locks produces no drift, and CI is green on both build and storyboard. LGTM.