Fix Maven Central publishing: invalid version from unoverridable GITHUB_REF

[kdroidFilter]

Context

gradle/libs.versions.toml is already pinned to the latest upstream PDFium (chromium/7934 / 152.0.7934.0) — the nightly auto-release bumped it on July 7. But nothing after 150.0.7857.0 ever reached Maven Central: tags v150.0.7869.0 → v152.0.7934.0 exist, master was fast-forwarded, yet Central still serves 150.0.7857.0 as latest.

Root cause

The auto-release publish job sets GITHUB_REF: refs/tags/v… in the step env: to drive publishVersion in pdfium/build.gradle.kts. GitHub Actions re-applies default variables after user env:, so the override never takes effect: Gradle sees refs/heads/master (schedule event), removePrefix("refs/tags/v") is a no-op, and publishing fails with:

Execution failed for task ':pdfium:publishAndroidReleasePublicationToMavenCentralRepository'.
> Invalid publication 'androidRelease': version cannot contain '/'.

(see run 28847340961, July 7). The tag is pushed before the publish step, so every failed run still leaves a release tag behind — which the guard then refuses to reuse.

Fix

• pdfium/build.gradle.kts: -PpublishVersion gradle property takes precedence; the GITHUB_REF fallback now only accepts actual refs/tags/v* refs instead of silently producing an invalid version.
• pdfium-auto-release.yaml: pass -PpublishVersion=<full_version> to the publish invocation instead of the ineffective GITHUB_REF env override.
• README: dependency snippet bumped to 152.0.7934.0b (the next release, see below).

The tag-push path (publish-maven.yaml) is unaffected — there GITHUB_REF genuinely is the tag ref.

Release plan

v152.0.7934.0 already exists as a git tag (from the failed July 7 run), so per the established convention the recovery release is v152.0.7934.0b, tagged on master after this merge. It ships PDFium 152.0.7934.0 plus the clickable-links feature from #9, and publish-maven.yaml rebuilds all JNI natives (including macOS/Windows) as part of the run.

Test plan

• Version resolution verified locally for all four cases: no input → 0.1.0, -PpublishVersion=152.0.7934.0b → 152.0.7934.0b, GITHUB_REF=refs/tags/v152.0.7934.0b → 152.0.7934.0b, GITHUB_REF=refs/heads/master → 0.1.0 (previously refs/heads/master)
• v152.0.7934.0b tag push publishes to Maven Central via CI
• Next nightly auto-release publishes inline without manual intervention

[kdroidFilter]

Added a second commit: the auto-release workflow now also creates the GitHub release explicitly — tags pushed with GITHUB_TOKEN don't trigger other workflows, so release-graalvm.yaml never fired for nightly bumps and v150.0.7869.0 → v152.0.7934.0 have no GitHub release either.