chore(deps): record exemptions for the crates the lockfile refresh moved

[BryanFRD]

Closes #1079.

Generated with cargo vet regenerate exemptions, the tool's own "make the check pass minimally", same as #1019 did after #906.

What changed

• 3 exemptions added, all criteria = "safe-to-deploy": multiversion, multiversion-macros, synstructure.
• 2 removed, find-msvc-tools and shlex, which are no longer dependencies.
• 26 version fields bumped on exemptions that already existed.
• Total goes 155 to 156.

supply-chain/imports.lock gains 89 lines and loses 58, which is the same regenerate pruning stale cached upstream audits for versions the tree no longer uses and pulling in current publisher entries. That part also fixes a smaller problem: cargo vet --locked has been failing on main since well before this, because every Renovate merge that moves a trusted publisher's crate leaves imports.lock behind. CI never noticed because it runs cargo vet without --locked, which refetches. Both forms pass on this branch.

Verification

$ cargo vet
Vetting Succeeded (161 fully audited, 1 partially audited, 156 exempted)
$ cargo vet --locked
Vetting Succeeded (161 fully audited, 1 partially audited, 156 exempted)
$ cargo audit --deny warnings
    Scanning Cargo.lock for vulnerabilities (320 crate dependencies)
$ cargo deny --all-features check
advisories ok, bans ok, licenses ok, sources ok

No code changes, so nothing to test beyond the supply-chain gates.

What this is and is not

An exemption records "not audited, accepted anyway". It is not an audit, and this is the second regenerate pass in about six weeks, each one adding to a number that only moves in one direction. It unblocks main and every open pull request today, and it writes the debt into a versioned file rather than leaving a check that fails until people stop reading it.

It does not answer #1017, which is still where the real decision sits: certify, import more audit sets, or stop running cargo vet.

[ferrfleet]

Checked the exemption deltas against the audit changes in imports.lock. The counts match the description (26 version bumps, 3 added, 2 removed, 155 to 156) and no exemption criteria were loosened. Nothing blocking.

Nit: the description says find-msvc-tools and shlex were dropped because they "are no longer dependencies". The diff says otherwise: imports.lock gains entries for both, a publisher record for find-msvc-tools plus deltas 0.1.0 -> 0.1.4 -> 0.1.8 -> 0.1.12, and shlex 1.1.0 (full) -> 1.3.0 -> 2.0.1. Regenerate prunes entries for crates that leave the tree rather than adding them, so both are still in it and are now covered by imported audits instead of exemptions. That is a better result than the description claims, but this PR exists to write the record down, so the record should be right.

Nit: two of the three additions are crates new to the tree, not re-versioned existing lines. multiversion / multiversion-macros 0.9.0 come in with the encoding_rs 0.8.41 bump and generate runtime CPU-feature dispatch (unsafe plus target_feature), and synstructure 0.14.0 falls off the end of the mozilla audit chain that covered it through 0.13.2, so a build-time proc macro that was audited no longer is. Exempting them is defensible, it is just a different decision than bumping a version on a line that already existed, and worth naming as such in #1017.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}