fix: validate update-tool binary identities

[sylvesterkaczmarek]

Summary

Make the committed update-tool lock validator verify each tool's expected executable identity, not only its crate name, version, URL, and checksums.

Problem

.cargo/tooling/update-tools.lock.toml records both the crate name and installed binary for cargo-audit and cargo-deny. script/validate-update-tools currently requires the binary field to be non-empty but never checks its value.

That creates an internal contract mismatch: the lock can pass the normal CI validation path with a wrong binary name, then fail later only when script/update calls install_locked_update_tool, whose installer independently requires the locked binary to match the executable it was asked to install.

Evidence / reproduction

• The current lock records name = "cargo-audit" / binary = "cargo-audit" and name = "cargo-deny" / binary = "cargo-deny".
• script/validate-update-tools validates the tool name, version, expected crates.io URL, crate digest, and packaged lockfile digest, but on the base commit it only checks that binary is non-empty.
• script/lib/update-tools.bash::install_locked_update_tool later contains an explicit binary-mismatch failure, so the installer already treats the binary identity as part of the lock contract.
• script/validate-locks runs script/validate-update-tools in both local and CI validation, so this is the boundary where a malformed committed lock should be rejected.
• Minimal reproduction on the base validator: change only binary = "cargo-audit" to another non-empty value while leaving the crate/version/URL/digests untouched. The lock validator accepts that field, but the subsequent update-tool installation rejects it as a binary mismatch.

Change

Require the binary to equal the reviewed tool identity for the two supported update tools (cargo-audit and cargo-deny) during lock validation.

This is a four-line validation change. No tool versions, downloads, runtime behavior, or update workflow semantics change.