chore: drop jni artifacts

[ovitrif]

Closes #114

Summary

• Stop tracking generated Android JNI .so files. publish-android.yml rebuilds them before packaging the AAR.
• Retain the upstream-aligned ldk-node-jvm project, generator, and runtime test while untracking its generated Kotlin and native resources.
• Remove the unused Synonym JVM publication workflow.
• Lock release dependencies and align Android publishing with Bitkit Android's NDK r28b (28.1.13356709).

Preview

N/A — no user-visible changes.

QA Notes

• Android JNI libraries are gitignored and rebuilt by publish-android.yml.
• The JVM runtime test harness remains and generates its ignored Kotlin and native resources before testing.
• The Synonym JVM package remains unpublished.
• This PR does not change UDL or tracked generated Swift, Kotlin Android, or Python sources.

Validation

• Exact PR head: 62515d13a414c76a5d1bfffce1554346b9534063; local HEAD and upstream match; worktree clean.
• Local verification: cargo fmt; git diff origin/main...HEAD --check; go run github.com/rhysd/actionlint/cmd/actionlint@v1.7.7 .github/workflows/publish-android.yml; binding shell scripts pass bash -n; JVM Gradle tasks and ktlintCheck pass; cargo metadata --locked --no-deps --format-version 1; cargo +1.85.0 check --locked --lib; cargo build --all-targets --locked; cargo test --lib --locked (102 passed); generated Android and JVM artifacts resolve to their .gitignore rules.

Stack

• fix: wait for broadcast result #113 is stacked on this branch and should merge after it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 51330a40ce

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coreyphillips]

Two independent reviews, nothing blocking a merge.

worth doing, does not block

• Release checklist omits Cargo.lock, so --locked builds fail right after a version bump (bindings/README.md:11). Committing Cargo.lock plus adding --locked to the JVM and Android builds makes Cargo.lock a version-bump artifact, but neither the rewritten checklist in bindings/README.md:11 nor AGENTS.md:250 lists it. Following the documented order (bump Cargo.toml at step 1, run ./bindgen.sh at step 3) fails at step 3: bindgen.sh reaches scripts/uniffi_bindgen_generate_kotlin.sh:14, whose cargo build --locked aborts because the lock still names the old crate version. The same happens in publish-android.yml via cargo ndk ... build --locked if a tag is pushed with a stale lock. Confirmed in a scratch crate: generated a lockfile, bumped only the manifest version, and cargo build --locked gave error: cannot update the lock file /private/tmp/locktest/Cargo.lock because --locked was passed to prevent this. Note that the cargo metadata --locked --no-deps in the PR's validation list does not catch this; it exited 0 on the same stale tree because --no-deps skips resolution. cargo metadata --locked without --no-deps exited 101. Smallest fix is to add Cargo.lock to both checklists (regenerate with cargo update -w after the bump).
• bindings/uniffi-bindgen/Cargo.lock is no longer gitignored and bindgen.sh creates it (.gitignore:4). The old .gitignore had an unanchored Cargo.lock rule that covered every lockfile in the tree. Replacing it with a tracked root lock leaves bindings/uniffi-bindgen/Cargo.lock unignored, and that crate is its own workspace (exclude = ["bindings/uniffi-bindgen"] in Cargo.toml:3). scripts/uniffi_bindgen_generate_python.sh:12 and scripts/uniffi_bindgen_generate_swift.sh:5 both run cargo run --manifest-path bindings/uniffi-bindgen/Cargo.toml, so every ./bindgen.sh run writes it. Confirmed two ways: git check-ignore -v bindings/uniffi-bindgen/Cargo.lock exits 1 on this branch, and copying bindings/uniffi-bindgen to a scratch directory and running cargo metadata produced a Cargo.lock next to the manifest. The practical cost is that it shows up untracked during the release flow, exactly at the step that says to commit the generated sources. Adding /bindings/uniffi-bindgen/Cargo.lock next to the existing /bindings/uniffi-bindgen/target/ rule covers it.
• Release checklist omits the required lockfile update (bindings/README.md:11). Following this checklist for the next version bump makes the first locked JVM build exit before generating bindings. Cargo.lock records the package version, but steps 1 through 3 change Cargo.toml and immediately run ./bindgen.sh. I confirmed this in an isolated HEAD archive by changing rc.66 to rc.67 and running the exact locked build, which exited 101 because the lockfile needed updating. Add a Cargo.lock refresh and commit before binding generation, including in the repository version checklist.
• Binding generation exposes a nested lockfile (.gitignore:5). Removing the catch-all Cargo.lock ignore exposes bindings/uniffi-bindgen/Cargo.lock, which the standalone Swift and Python generator workspace creates. In a temporary clean tree, resolving that manifest created the nested lockfile and git status --short reported it as untracked. Every documented ./bindgen.sh run now dirties the checkout, so this nested lockfile needs a scoped ignore.