sync-lockfiles: support the rebuilt zenoh-java/zenoh-kotlin (add zenoh-flat, zenoh-flat-jni; drop the crate-path special case)

[milyin]

Everything sync-lockfiles needs for the rebuilt zenoh-java / zenoh-kotlin, in
five changed lines: two new dependants, and the removal of the special case that
existed for the two old ones.

   - eclipse-zenoh/zenoh-kotlin
+  - eclipse-zenoh/zenoh-flat
+  - eclipse-zenoh/zenoh-flat-jni

-      - name: Compute crate path of ${{ matrix.dependant }}
-        run: |
-          if [[ "${{ matrix.dependant }}" =~ eclipse-zenoh/zenoh-(java|kotlin) ]]; then
-            echo "value=zenoh-jni" >> $GITHUB_OUTPUT
...
-          path: ${{ steps.crate-path.outputs.value }}
+          path: .

Background: what changed in the SDKs

zenoh-java and zenoh-kotlin no longer contain a Rust JNI crate. Their bindings
are generated from a single annotated Rust surface and shipped as a separate
library:

zenoh ──> zenoh-flat ──> zenoh-flat-jni ──> zenoh-java
                                        └─> zenoh-kotlin

• zenoh-flat — the annotated Rust surface multi-language bindings are
  generated from. Depends on zenoh / zenoh-ext in the usual version +
  git + branch = "main" shape.
• zenoh-flat-jni — the JNI/Kotlin binding generated from it, published as
  org.eclipse.zenoh:zenoh-flat-jni. Depends on zenoh, zenoh-ext and
  zenoh-flat.

Both commit a Cargo.lock and carry a rust-toolchain.toml (channel = "1.97.1", matching zenoh), which is what this workflow needs from a dependant.
They are two more zenoh bindings that have to stay ABI-aligned with zenoh, and
today nothing keeps them aligned.

Why the crate-path step goes

It exists for exactly two repositories — the zenoh-(java|kotlin) → zenoh-jni
branch above — and zenoh-jni/ no longer exists in either of them (merged
2026-08-10: eclipse-zenoh/zenoh-java#482, eclipse-zenoh/zenoh-kotlin#669). The
last sync run predates that, so the next run — the next push to zenoh’s main
touching its Cargo.lock — points both jobs at a
manifest that is gone. This PR is what restores them, not a cleanup.

What each SDK keeps instead is a manifest at the repository root, whose
lockfile records the zenoh-flat-jni commit its CI builds against:

# zenoh-kotlin/Cargo.toml — a pin crate, compiles to nothing anyone ships
[dependencies]
zenoh-flat-jni = { git = "https://github.com/eclipse-zenoh/zenoh-flat-jni.git", branch = "main" }

Cargo.lock:  source = "git+https://github.com/eclipse-zenoh/zenoh-flat-jni.git?branch=main#<40-hex commit>"

That commit is the pin their Gradle build reads and checks out, and this workflow
already knows how to move it, with no new step: overwrite the lockfile with
zenoh's — which carries no zenoh-flat-jni entry, so the pin is removed —
rectify by resolving again, which writes the current commit back and compiles it.
Same sync, same auto-merging pull request, no special casing. The SDKs chose a
lockfile as their pin precisely so that this workflow, unmodified, is what keeps
them current.

With no dependant left below the toplevel, the step, its if, and the three
interpolations of its output all go. zenoh-c's build-resources/opaque-types
steps are unaffected — they always named their manifest explicitly.

Two things I expected to need, and verified are not needed

A crate path for the new entries. Both keep their manifest at the root, so
the default . is right. The old special case did not false-match them either —
the pattern needs zenoh- immediately followed by java/kotlin, and
zenoh-flat-jni has flat-jni there:

eclipse-zenoh/zenoh-flat-jni  -> .
eclipse-zenoh/zenoh-flat      -> .

A cargo update zenoh-flat step. zenoh-flat-jni is the first two-level
dependant here — it reaches zenoh both directly and through zenoh-flat — so I
expected the hardcoded cargo update zenoh to leave the intermediate crate
stale. It does not, and the reason is structural: zenoh's lockfile has no
zenoh-flat entry at all, so overwriting the dependant's lock with it removes
that pin, and the rectify step then resolves the git dependency fresh from
branch = "main". Ran the full sequence locally against zenoh's real
Cargo.lock to confirm:

zenoh Cargo.lock contains zenoh-flat:  no
after overwrite + rectify:
  zenoh-flat -> git+…/zenoh-flat.git?branch=main#86cfb75   (= zenoh-flat main HEAD)
  cc         -> 1.4.0                                      (= zenoh's pin, preserved)

So the intermediate crate refreshes on every sync for free, and zenoh's pins
survive — which is the property the sync exists for. An explicit update step
would have been dead weight. The same argument is what makes the SDK pin work:
zenoh-flat-jni is absent from zenoh's lockfile for exactly the same reason.

Verifying

workflow_dispatch on this branch and check the zenoh-flat, zenoh-flat-jni,
zenoh-java and zenoh-kotlin jobs. Each should open a lockfile pull request
against its dependant. fail-fast: false already keeps one dependant's failure
off the others, and nothing outside those four jobs is touched.

The crate-path removal needs the root manifest on each SDK's default branch —
eclipse-zenoh/zenoh-kotlin#700 and eclipse-zenoh/zenoh-java#521. Until those
land, the two SDK jobs fail on a missing root Cargo.toml rather than on the
missing zenoh-jni/Cargo.toml they hit today.

[diogomatsubara]

LGTM