chore(deps): document dev-only FluxBench advisories

[presempathy-awb]

Summary

Keep PageDB's dependency audit actionable after two RustSec
unmaintained-crate advisories began matching FluxBench's dev-only CLI and
reporting dependency tree.

This change adds narrowly documented exceptions for:

• RUSTSEC-2025-0057 (fxhash is unmaintained); and
• RUSTSEC-2025-0119 (number_prefix is unmaintained).

No dependency version, package source, production feature, benchmark behavior,
or published PageDB payload changes.

Why an exception is the correct current disposition

The audit was rerun against the current RustSec database from exact GitHub
main 4a6c85314af1d1596dac73d1270afde37149c48a. Both advisories fail the audit,
but neither reports a vulnerability with a fixed release. They report that the
crate is no longer maintained.

The current dependency paths are:

fxhash
├── fluxbench-cli
│   └── fluxbench
│       └── pagedb [dev-dependency]
└── fluxbench-logic
    └── fluxbench / fluxbench-cli / fluxbench-report

number_prefix
└── indicatif
    └── fluxbench-cli
        └── fluxbench
            └── pagedb [dev-dependency]

cargo search fluxbench and cargo info fluxbench both report 0.1.3 as the
latest release. PageDB already uses 0.1.3, so there is no newer FluxBench
release to evaluate. RustSec reports no safe direct upgrade for either
transitive crate. PageDB also cannot replace a transitive implementation inside
the published FluxBench crates without adding a Git source, local patch, or
fork; each would weaken the repository's existing crates.io-only source policy
and create a much larger maintenance decision than the advisory warrants.

The exceptions are therefore explicit risk acceptances at the correct
boundary. They are not wildcard ignores, version-wide advisory suppression, or
an assertion that unmaintained dependencies are harmless in general. Each
comment records:

• the current FluxBench release boundary;
• the exact dev-only path;
• the fact that the dependency is absent from PageDB's normal/build graph; and
• the lack of a safe upgrade.

If FluxBench publishes a release that removes either dependency, these
exceptions should be deleted in the same dependency update.

Consumer and release boundary

FluxBench is a root-package development dependency used by PageDB-owned
benchmarks. It is not in the library's normal or build dependency graph.
PageDB consumers therefore do not compile or link fluxbench, fxhash,
indicatif, or number_prefix.

That separation was checked directly with:

cargo tree -p pagedb --edges normal,build --locked --prefix none |
  grep -E '^(fluxbench|fxhash|indicatif|number_prefix) '

The command produced no matches. The existing manifest-hygiene regression also
keeps benchmark-only engines and the isolated comparison workspace out of the
normal PageDB package graph.

This PR does not move FluxBench into production, make benchmarks a release
prerequisite, add RocksDB/SQLite/redb, or add a native toolchain dependency.
It only teaches cargo-deny about two reviewed dev-tool exceptions so new
security, yanked-crate, license, source, and ban findings continue to fail
normally.

Verification

Fresh verification from the exact candidate:

cargo deny check
  advisories ok
  bans ok
  licenses ok
  sources ok

The audit still reports the repository's existing non-blocking warnings for
duplicate versions and unused license allowances. Neither exception changes
those policies.

The normal/build graph isolation command above returned no matching package.
git diff --check passed, and the final diff is one file with no generated
lockfile change.

Scope and risk

The operational risk is intentionally small: a future FluxBench code path could
make one of these unmaintained crates more important while the advisory stays
ignored. The comments make the acceptance predicate reviewable: latest
FluxBench release, dev-only reachability, no consumer graph, and no safe
upgrade. Any dependency update should re-run cargo tree -i fxhash,
cargo tree -i number_prefix, and cargo deny check; if the path or available
versions change, the corresponding exception no longer has its stated basis.

The alternative of leaving the audit red is worse because it makes every
future dependency PR and release-safety PR fail for known, non-remediable
dev-tool findings. The alternative of disabling advisory checks for dev
dependencies would be broader and would hide future vulnerabilities in test
and benchmark code. The alternative of forking FluxBench would add a
long-lived source and maintenance boundary solely to replace two transitive
unmaintained crates.

This PR keeps the strict audit while documenting the two facts it cannot
currently remediate.

[farhan-syah]

Closing unmerged — both advisories are fixed upstream rather than needing an exception.

FluxBench 0.1.4 was published on 2026-07-26, after this PR's audit was run. It removes both crates outright:

Advisory	Crate	0.1.3 path	0.1.4
RUSTSEC-2025-0057	fxhash	fluxbench-cli, fluxbench-logic	replaced by rustc-hash ^2
RUSTSEC-2025-0119	number_prefix	indicatif ^0.17 → number_prefix	indicatif ^0.18 → unit-prefix

So the correct disposition is a lockfile bump, not a risk acceptance. deny.toml's ignore list stays empty.

Verified against the bumped lockfile:

• fxhash and number_prefix: no entries left in Cargo.lock
• cargo deny --exclude-dev check (the CI audit job): advisories ok, bans ok, licenses ok, sources ok
• cargo deny check (full, including dev deps): same, with only the pre-existing duplicate-version and unused-license-allowance warnings
• cargo bench --no-run -p pagedb --bench segment: compiles clean — the upgrade is drop-in

One note for whoever runs the bump: cargo update -p fluxbench alone is not enough. The sub-crates depend on each other via ^0.1.0, which 0.1.3 satisfies, so they stay pinned unless named explicitly.

The reasoning in this PR was sound for the state of the world it was written against — per-advisory rather than wildcard, dev-only reachability checked directly, and it explicitly declined the broader "disable advisories for dev dependencies" option. It also named its own expiry condition: "If FluxBench publishes a release that removes either dependency, these exceptions should be deleted." That condition is now met.

Two things worth carrying forward:

• cargo info / cargo search read a local registry index that can be stale — they reported 0.1.3 here well after 0.1.4 was live. For "is there a newer release", the crates.io API or cargo update --dry-run is the sound check.
• The CI audit job runs cargo deny --exclude-dev check, so these advisories only ever failed a local full check, never the gate. Worth distinguishing the two when a future exception is proposed.

Thanks for the thorough write-up — the dependency-path analysis made this quick to confirm.