fix(ci): sync Cargo.lock after version bump so --locked steps pass

The release step rewrites the crate version in Cargo.toml (0.1.0 -> next),
which desyncs this crate's own entry in Cargo.lock. The following
`cargo test/build --locked` steps then abort:

    error: cannot update the lock file ... because --locked was passed

Run `cargo update --manifest-path sidecar/Cargo.toml --workspace` right
after the bump: it updates only the workspace member's version in the lock
and leaves every dependency pin untouched, so --locked still guarantees
reproducible deps. Verified locally — reproduced the exact failure, then
confirmed the sync makes `cargo build --locked` succeed with 6 dependencies
unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

.gitea/workflows/release.yml

@@ -155,6 +155,11 @@ jobs:
           # Replace only the [package] version (the first `version = "..."`).
           sed -i -E "0,/^version = \"[^\"]+\"/s//version = \"${VERSION}\"/" "${WORKDIR}/Cargo.toml"
           grep -m1 '^version' "${WORKDIR}/Cargo.toml"
+          # Bumping the manifest version desyncs this crate's own entry in
+          # Cargo.lock, which would make the `--locked` fmt/test/build steps below
+          # fail ("cannot update the lock file ... --locked was passed"). Sync just
+          # the workspace member(s) into the lock — dependency pins are untouched.
+          cargo update --manifest-path "${WORKDIR}/Cargo.toml" --workspace
 
       # ── RUST ADAPTER: gates ──────────────────────────────────────────────
       - name: cargo fmt --check