cargo deny: fix wildcard path dependencies

[noahgift]

Problem

cargo deny check bans fails because workspace path dependencies lack version specifiers:

error[wildcard]: path = "../sibling" without version = "x.y.z"

Wildcard dependencies bypass crates.io resolution. If a path dep changes its API, downstream crates silently break when published. This is banned by the fleet deny.toml (wildcards = "deny").

Fix

Add version = "x.y.z" to every path dependency in Cargo.toml:

# Before (wildcard — banned)
sibling = { path = "../sibling" }

# After (versioned — allowed)
sibling = { version = "0.1.0", path = "../sibling" }

The version must match the dep's Cargo.toml version field. Path takes precedence for local builds; version is used by crates.io.

Five-Whys Root Cause Analysis

Why does cargo deny check fail?
Because the dependency graph contains crates with known vulnerabilities, missing licenses, unmaintained status, or wildcard version specifiers.

Why are these issues present?
Because dependency hygiene was not enforced at commit time — cargo deny ran only in nightly CI as an advisory check, not as a blocking gate.

Why wasn't it a blocking gate?
Because the deny.toml template was deployed without verifying each repo's dependency graph passes. The template was designed for the core sovereign stack (trueno, batuta, forjar, etc.) and deployed uniformly to all 89 Rust repos.

Why wasn't each repo verified?
Because the fleet grew from 25 core repos to 200+ repos organically. Non-core repos (cookbooks, POCs, course material) received CI tooling but not dependency audits.

Why did the fleet grow without audits?
Because there was no supply-chain gate in the PR workflow — the org ruleset enforces CI status checks (gate) but cargo deny was not a required check. The PR authorization gate (Phase 8) blocks unauthorized contributors but not unauthorized dependencies.

Root Cause

Lack of shift-left dependency enforcement. The supply chain security controls (deny.toml, cargo-deny) existed as tooling but were not integrated as blocking CI gates. This matches the empirical finding in Alfadel et al. (arXiv:2203.04520) that 69% of npm vulnerabilities persist because developers lack automated, blocking remediation workflows. Zahan et al. (arXiv:2112.10561) found that >50% of OSS projects have no dependency update policy, leading to systemic vulnerability lag.

References

• Alfadel et al., "Empirical Analysis of Security Vulnerabilities in npm Packages" (arXiv:2203.04520) — 69% of vulnerabilities persist due to lack of automated remediation
• Zahan et al., "Weak Links in the npm Supply Chain" (arXiv:2112.10561) — >50% of projects lack dependency update policies
• Ohm et al., "Backstabber's Knife Collection: A Review of Open Source Supply Chain Attacks" (arXiv:2005.09535) — taxonomy of supply chain attack vectors via abandoned/unmaintained packages
• Lauinger et al., "Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web" (arXiv:1811.00918) — quantifies dependency lag and its security implications