ws-sync: cargo update runs after uv sync, so a stale Cargo.lock is unrecoverable

`ws_sync` runs `_cargo_update` (core.py:365) only *after* `subprocess.run(["uv","sync","-U"], check=True)` (core.py:363), so a member crate whose `Cargo.lock` pins a stale git rev — exactly what `cargo update` fixes — fails the `uv sync`, raises `CalledProcessError`, and never reaches the cargo pass or the daily stamp, so every later `ws-sync` fails the same way.

Repro: in a workspace member with an unpinned git dependency, let the dependency's source move ahead of the locked rev (here `mdhtml` -> `fast5ever`, whose new `Dom::rename` the locked rev lacks) and run `ws-sync`; it dies building that crate, and only a manual `cargo update` in the crate unblocks it.