Fix Maven Central publish for vespera-bridge + gradle plugin

[owjs3901]

Why

Run #26458007485 failed to publish vespera-bridge@0.1.0 and vespera-bridge-gradle-plugin@0.1.0 to Maven Central. Three independent regressions stacked together caused it:

1. shouldSign probed the wrong property → unsigned artifacts → Central Portal rejection

32b712a replaced the unconditional signAllPublications() call with:

val shouldSign = !providers.gradleProperty("signingInMemoryKeyId").orNull.isNullOrBlank()
        || !System.getenv("ORG_GRADLE_PROJECT_signingInMemoryKeyId").isNullOrBlank()

mavenPublishing {
    publishToMavenCentral(automaticRelease = true)
    if (shouldSign) signAllPublications()
}

But CI.yml only sets:

• ORG_GRADLE_PROJECT_mavenCentralUsername / Password
• ORG_GRADLE_PROJECT_signingInMemoryKey ← the actual key
• ORG_GRADLE_PROJECT_signingInMemoryKeyPassword

signingInMemoryKeyId is never set anywhere, so shouldSign evaluated to false and signAllPublications() was skipped. Central Portal received unsigned artifacts and rejected the deployment — the gradle log ends at Deployment is being validated and never progresses to is being published (the successful 0.0.14 log shows both lines).

Maven Central confirms 0.0.14 was the last published version.

2. Plugin's gradlew had no executable bit

The new libs/vespera-bridge-gradle-plugin directory was added by 32b712a but the workflow's chmod step still only touched libs/vespera-bridge/gradlew. changepacks runs ./gradlew publishToMavenCentral from each Java project's directory, so the plugin invocation failed immediately with no log output (the failing run's publish output for libs/vespera-bridge-gradle-plugin/build.gradle.kts: line is empty).

3. .changepacks/config.json didn't track the new plugin

Cargo-driven version bumps only bumped vespera-bridge, never the plugin. Future Cargo bumps would silently leave the plugin behind.

Changes

• libs/vespera-bridge/build.gradle.kts, libs/vespera-bridge-gradle-plugin/build.gradle.kts — probe signingInMemoryKey (the actual key) instead of signingInMemoryKeyId.
• .github/workflows/CI.yml — chmod +x both gradlew binaries.
• libs/vespera-bridge*/gradlew — index filemode set to 100755 (defense-in-depth so the workflow chmod is no longer load-bearing on Linux runners).
• .changepacks/config.json — updateOn now lists both Java packages.
• .changepacks/changepack_log_*.json — Patch bump for both Java packages (Maven Central does not allow re-uploading the rejected 0.1.0, so this triggers an Update Versions PR for 0.1.1).

Verification plan

After merging this PR, the auto-generated Update Versions PR will bump bridge/plugin 0.1.0 → 0.1.1. When that PR merges, the CI publish step should now:

1. chmod +x both gradlew binaries (defense; index already has 100755).
2. Run ./gradlew publishToMavenCentral --stacktrace for both Java packages.
3. shouldSign = true → signAllPublications() runs → signed artifacts → Central Portal validation passes → release.

Cargo 0.2.0 was already published successfully and stays unchanged.

[github-actions]

Changepacks

vespera@0.2.0 - Cargo.toml

Maybe you forgot to write the following files to the latest version

vespera-bridge@0.1.0 → 0.1.1 - libs/vespera-bridge/build.gradle.kts

Patch

• Fix Maven Central publish: probe signingInMemoryKey (the actual private key, which CI sets) instead of signingInMemoryKeyId (which CI does not set); also chmod +x both gradlew binaries

vespera-bridge-gradle-plugin@0.1.0 → 0.1.1 - libs/vespera-bridge-gradle-plugin/build.gradle.kts

Patch

• Fix Maven Central publish: probe signingInMemoryKey (the actual private key, which CI sets) instead of signingInMemoryKeyId (which CI does not set); also chmod +x both gradlew binaries