chore: three items from the open-issue audit

[LKSNDRTMLKV]

Three small items from the open-issue audit. No behaviour changes — one comment
correction, one dead dependency, one stale comment block.

docs(docker) — the resolver's fixed uid is part of the deployment contract (#139)

resolver.Dockerfile justified its fixed uid with "the resolver has no local
state (Redis + upstream vault only), so no volume ownership to worry about".
That is no longer true: a deployment enabling scan telemetry over mTLS
bind-mounts a host PEM via SCAN_FLUSH_CLIENT_IDENTITY, and the file is
mode-restricted because it holds a private key — so its host owner has to match
uid 1000 for the resolver to read it.

Two things worth recording against the issue as filed:

• The exposure is narrower than The fixed uid in the runtime images is now load-bearing for host bind mounts #139 describes. No compose file mounts a
  volume into the resolver; the bind mount is operator-supplied in a production
  deployment, and the .env.example line is commented out. The comment is
  conditionally stale, not flatly wrong.
• The failure is loud, not silent. The fixed uid in the runtime images is now load-bearing for host bind mounts #139 says it "presents as silence rather
  than as an error". It does not — build_scan_flush_client is called from the
  startup path at main.rs:188 with ?, so an unreadable PEM aborts boot with
  a contextual error naming the path. That lowers the severity considerably.

node.Dockerfile is left alone: its comment says the published deployment path
only binds named volumes, and that is still accurate — the node service mounts
node-data and node-plugins, both named.

chore(deps) — drop dpp-node's unused serde_jcs (#68, item 1)

Nothing under crates/ or cli/ references it; the only surviving mentions are
a doc comment in calc_battery.rs describing what dpp-calc pulls in, and a
note in dpp-types/Cargo.toml recording the refactor that orphaned it.

The hazard #68 describes is already gone. It argued this was "two
canonicalisers in one signing binary" with the risk of signing bytes core's
verifier cannot reproduce. The lock has a single serde_jcs 0.2.0, reached
transitively by dpp-calc, dpp-crypto, dpp-rules and dpp-vc. The
workspace manifest already said "0.2", not the "0.1" the issue recorded.
What was left was one redundant declaration, and this removes it.

Items 2 (zip 0.6.6 vs 8.6.0) and 3 (image 0.23.14 vs 0.24.9) are untouched
and still live — cargo deny check bans still reports both.

docs(deny) — reconcile the duplicate-count comments (#68, side finding)

[bans] carried two overlapping comment blocks justifying
multiple-versions = "warn", one claiming ~70 duplicated pairs and the other
~172. Both were stale and they contradicted each other. Replaced with a single
block carrying a dated, measured number (64 distinct crates / 148 crate-version
entries, 2026-08-22, Windows) and an explicit note that the figure is platform
dependent and wants re-measuring on Linux before anyone acts on it.

Verification

just fmt-check and just lint green; cargo deny check bans reports
bans ok; cargo check -p dpp-node clean after the dependency removal.

Closes #139.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}