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

[KeremTurgutlu]

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.