chore(deps): refresh benchmark chacha20 lock resolution

[presempathy-awb]

Summary

Update the benchmark-only chacha20 resolution from yanked 0.10.1 to
non-yanked 0.10.2 in Cargo.lock.

This is lockfile maintenance for the FluxBench statistics path. The crates.io
API currently reports chacha20 0.10.1 as yanked and 0.10.2 as available and
not yanked. Both releases declare MIT OR Apache-2.0, require Rust 1.85, and
belong to the same 0.10 family. The registry checksum changes from
d524456ba66e72eb8b115ff89e01e497f8e6d11d78b70b1aa13c0fbd97540a81 to
65c35e4b699c7e15ccbe7ee35c005e4fc0a278d22238a2857e6ce2dadeda1b06.

Exact scope

The diff is one file and three mechanical lockfile lines:

• chacha20 version 0.10.1 becomes 0.10.2;
• its registry checksum is refreshed; and
• rand 0.10.2's dependency pointer follows the resolved version.

No package was added or removed. The update was first checked with:

cargo update -p chacha20@0.10.1 --precise 0.10.2 --dry-run --verbose

That dry run proposed only the targeted version update. The applied command
was the same without --dry-run.

The distinct production cryptography dependency chacha20 0.9.1, used through
chacha20poly1305 0.10.1, is unchanged. The FluxBench family remains eight
packages at 0.1.4; evalexpr remains 13.1.0; rkyv and rkyv_derive
remain 0.8.17. No manifest, dependency policy, source, benchmark, or workflow
file changed.

Audit evidence and limits

Before the lock update, both of these local graph-wide advisory checks exited
1 because chacha20 0.10.1 was yanked through
rand 0.10.2 -> fluxbench-stats 0.1.4:

cargo deny check advisories
cargo deny --all-features check advisories

After the update, both report advisories ok. The corresponding configured
full checks, cargo deny check and cargo deny --all-features check, report
advisories ok, bans ok, licenses ok, sources ok, with the repository's
existing duplicate-package and unmatched-license warnings.

Those local graph-wide results should not be described as repairing broken
upstream CI. The workflow's exact gate is cargo deny --exclude-dev check, and
it passes; because --exclude-dev omits the benchmark development dependency
path, the yanked 0.10.1 did not fail that production-scoped gate before this
maintenance update. The patch removes the stale/yanked lock resolution when
the development graph is audited locally.

Nor is the configured license result full benchmark-license certification.
Cargo-deny 0.20.2 defaults [licenses].include-dev to false independently of
--all-features. An ephemeral, non-persisted check with include-dev = true
rejects FluxBench's dev-only evalexpr 13.1.0 as AGPL-3.0-only. This patch
does not allow AGPL, add an exception, change policy, or change benchmark-tool
source. That separate license disposition remains for maintainer review.

Build and bounded benchmark smoke

Both compile-only validations pass with the updated locked graph:

cargo bench --locked --no-run -p pagedb --bench segment
cargo bench --locked --no-run -p pagedb

The package-wide command builds the five existing benchmark binaries:
authenticated_node_read, compaction, read_path, segment, and
write_path.

The compiled upstream segment binary was also run through its native FluxBench
CLI with a single fixed sample, in process:

segment-7b9ded8e03e89cef baseline_aesgcm_only \
  --samples 1 --isolated=false --format json --output <temporary-file>

It completed one baseline_aesgcm_only result and emitted the allocation
metrics wired by the benchmark's existing global allocator (alloc_count: 128,
alloc_bytes: 514048). This is only compatibility and instrumentation evidence
from a one-sample smoke. It is not a stable measurement and makes no timing,
throughput, allocation-improvement, or comparative performance claim.

Review and rollback

Review should confirm the three-line semantic lock change, the separation from
the production chacha20 0.9.1 path, and the intentionally unchanged license
policy. Rollback is a direct reversion of the lockfile update; no source or
schema migration is involved.

An independent bounded review found no must-fix or should-fix issue in the
lockfile scope or the claims above. No manifest edit, policy exception, or
global tool installation was made.