chore(deps): trust libc's trusted publisher in cargo vet

[BryanFRD]

Closes #1264

cargo vet has failed on main since #1263 moved libc to 0.2.190. That release was published by the rust-lang/libc GitHub workflow through crates.io trusted publishing (run 37054821350), so crates.io records no user publisher, and our [[trusted.libc]] entry for rust-lang-owner (user 55123) no longer covers it.

This adds a second [[trusted.libc]] entry for github:rust-lang/libc, from the date of the first trusted-published version, generated with cargo vet trust libc github:rust-lang/libc --criteria safe-to-deploy. The rust-lang-owner entry stays for older versions. cargo-vet also refreshed imports.lock and dropped two publisher-name comments it derives from it.

cargo vet passes locally: 162 fully audited, 1 partially audited, 157 exempted.

CI also needed a newer cargo-vet: taiki-e/install-action at our pinned SHA resolves cargo-vet@latest to 0.10.0, which cannot parse a trusted-publisher entry (missing field user-id). The job now installs cargo-vet@0.10.2, the version used to generate the entry.

This is also why #1263 went green: cargo vet is advisory on lockfile-only Renovate PRs, so the failure only surfaced on main.

[ferrfleet]

Nothing blocking. The new [[trusted.libc]] entry is scoped to github:rust-lang/libc from the first trusted-published release (2026-10-02), and the existing user 55123 entry still covers older versions. The two dropped # rust-lang-owner comments are cosmetic. cargo-vet derives them from imports.lock, which no longer records that login for libc.

[ferrfleet]

aff3e30 (pinning cargo-vet@0.10.2) looks right: without it, CI's install-action resolves to 0.10.0, which can't parse the new trusted-publisher entry. The cargo-vet job hadn't reported on this commit when I checked, so I haven't confirmed it passes in CI.

Nit: the other tools on that line still float to latest. Make sure Renovate picks up this pin, or it will stay on 0.10.2 indefinitely.