[jamesyong-42]

Both audits went red on main after #70's checks. Two advisories entered their databases on 2026-10-23, both after main's last clean audits at 09:06Z. This PR moves the two lockfiles and changes no source or manifest.

50343dd: tokio 1.53.3 for RUSTSEC-2026-0386.

• The advisory: dated 2026-10-13, it entered the RustSec database at 14:42Z on 2026-10-23. It is informational "unsound": tokio's safe AsyncFd constructors (new, with_interest, try_new, try_with_interest) accept any T: AsRawFd, so safe code can register a descriptor it does not own.
• The fix upstream: tokio 1.51.6 and 1.53.3 patch it by deprecating those constructors in favor of the unsafe AsyncFd::register. 1.52.3 is affected.
• Why the audit fails: .cargo/audit.toml denies warnings.
• Path: tokio 1.52.3 ← truffle-core 0.7.19, ghosttea, ghosttead and ghosttea-truffle, and through tokio-util, quinn and tokio-tungstenite.
• Exposure read: there is no AsyncFd call in ghosttea's Rust sources, in truffle-core 0.7.19, or in tokio-util 0.7.18, quinn 0.11.11 and tokio-tungstenite 0.29.0. The rest of the dependency tree was not checked.
• The change: cargo update -p tokio --precise 1.53.3, and cargo metadata --locked agrees. tokio 1.53.3 needs Rust 1.71, under the workspace's 1.88.

Cargo also re-points six windows-sys edges. The same command makes cargo's resolver move six packages' windows-sys edge from 0.61.2 to 0.52.0: errno 0.3.14, quinn-udp 0.5.15, rustix 1.1.4, rustls-platform-verifier 0.7.0, tempfile 3.27.0 and winapi-util 0.1.11.

• Each of the six declares a windows-sys range that admits both versions.
• Both versions were already in the lock, and no package is added or removed. tokio's own edge stays on 0.61.2.
• It affects Windows targets only. This PR's Windows gate and lifecycle soak exercise it.
• It is not avoidable without hand-editing the lock. Setting the ghosttea-config patch line aside (f17a0ff's method) gives the same lock, and so does tokio 1.54.1.

The iOS inventory records the lock's hash, so its documented chain regenerated it, as #69 did. Only cargoLockSha256 and the hashes derived from it move. tokio is not an iOS component.

f88df38: zod 4.6.7 for GHSA-mrhx-c7xc-m3w5 (CVE-2023-54404, high): "Zod can exhaust memory while validating oversized constrained collections", zod < 4.6.6.

• Timing: it was first published on 2026-10-01 unreviewed. GitHub reviewed it at 18:26Z on 2026-10-23, and that is when npm audit --audit-level=high began failing on it.
• Dev-only: zod 4.4.3 comes in through eslint-plugin-react-hooks 7.1.1 (zod: ^3.25.0 || ^4.0.0) and zod-validation-error 4.0.2. The lock marks it dev. No published package ships zod, so nothing a consumer installs changes.
• The change: npm update zod --package-lock-only --ignore-scripts moves zod alone to 4.6.7, the newest 4.x. No manifest changes.
• Left as they are: three dev-only moderates, @vitest/mocker (through vitest) and fast-uri 3.1.8.

Expected red: audit-published. This tree's Apple native source digest (0c82a3a6…) still differs from the pinned 0.13.1 artifact's (fa08d019…), as it has since #69. Cargo.lock is one of that digest's inputs. 0.13.2 republishes the artifact.

Checks

• Desktop gates 40044989270 and iOS release hardening 40044991615 run on the head, and this PR's own checks run as well.
• Local checks:
  • cargo audit is clean (263 crates), and npm audit at high is 0;
  • the iOS BOM, release-resources and App Store checks pass, and so does check:swiftpm:manifests;
  • Prettier over format:check's paths passes.
• Both audits ran in the push command itself, and the push ran only because both exited 0.
• No source file changes.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}