chore(deps): update the dependency graph; hold egui at 0.35 (upstream wasm break)

[doublegate]

Summary

Consolidates the five open Dependabot PRs into one graph update. Two are
adopted, one is a CI action pin, and three are declined on evidence rather
than deferred.

Supersedes #387, #388, #389, #390, #391 — all five to be closed on merge.

Adopted

cargo update across the whole graph: roughly 80 crates, all semver-compatible,
no source changes required. anyhow 1.0.103 → 1.0.104, cc 1.4.0 → 1.4.3,
cpal 0.18.1 → 0.18.2, the futures-* family 0.3.33 → 0.3.34, the icu_*
family 2.2 → 2.3, http 1.4.2 → 1.5.0, plus bstr, camino, clang-sys,
darling, either, inotify and the rest.

Plus #387: taiki-e/install-action v2.85.10 → v2.85.13 at both call sites in
security.yml.

Cargo.toml itself is unchanged apart from nothing — every adopted bump is a
lockfile move within the existing ranges.

Declined, with the reason established by experiment

#389 / #390 / #391 — egui, egui-wgpu, egui-winit 0.35 → 0.36.1.
egui-winit 0.36.1 does not compile for wasm32-unknown-unknown, and RustyNES
ships a wasm demo:

error[E0407]: method `bytes` is not a member of trait `egui::DroppedFile`
  --> egui-winit-0.36.1/src/dropped_file.rs:19:5

The mechanism, since "blocked upstream" is not a diagnosis. egui 0.36 turned
DroppedFile into a trait and split it by target: bytes_async on wasm
(a browser can only read a dropped file asynchronously), bytes on native.
egui-winit's NativeFile impl provides path + bytes with no cfg gate,
on a type that holds a PathBuf and calls std::fs::read — inherently native.
On wasm it therefore implements a method the trait does not declare and omits
the one it does.

Nothing on our side can route around it: mod dropped_file; is unconditional in
egui-winit's lib.rs, so the module compiles on wasm whatever we do. The fix is
a one-line cfg upstream. No release carries it — 0.36.1 is still the newest
egui-winit on crates.io.

wgpu is held at 29 for the same reason: egui-wgpu 0.35 pins it, so 29 → 30
cannot land ahead of the egui tier.

This confirms rather than assumes the note in AGENTS.md (added when the
migration was first attempted and parked on chore/egui-0.36-wgpu-30-blocked).
I re-ran the build instead of trusting it, because a "blocked" note is exactly
the kind of claim that goes stale silently — and the useful output of
re-checking is the specific method name a future attempt needs, bytes_async,
rather than a bare verdict.

Verification

gate	result
cargo clippy --workspace --all-targets -- -D warnings	clean
scripting / scripting,hd-pack / retroachievements / full	clean
wasm32-unknown-unknown (default and wasm-canvas)	clean
RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps	clean
cargo build -p rustynes-core --target thumbv7em-none-eabihf --no-default-features	clean
cargo deny check	advisories ok, bans ok, licenses ok, sources ok
workspace tests	124 test binaries, all green

No emulation-core source changed, so the accuracy contract is unaffected by
construction; the full suite ran regardless.

[coderabbitai]

Important

Review available on request

• 🔍 Trigger review

Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment @coderabbitai review to review the latest changes. For a full review, comment @coderabbitai full review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 34ecb617-e0b6-4b55-ba46-f549af410caa

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

This PR consolidates several Dependabot updates into a single dependency-graph refresh, updating the workspace lockfile while explicitly keeping the egui stack pinned at 0.35 due to an upstream wasm build break in egui-winit 0.36.x. It also bumps the taiki-e/install-action GitHub Action used by the security workflow.

Changes:

• Refreshes the Rust dependency graph via lockfile updates while keeping egui, egui-winit, and egui-wgpu at 0.35.0 and wgpu at 29.0.4.
• Updates .github/workflows/security.yml to use taiki-e/install-action@v2.85.13 in both the audit and cargo-deny jobs.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/security.yml	Bumps taiki-e/install-action to v2.85.13 for the security audit/deny jobs.
Cargo.lock	Updates the resolved dependency graph while keeping the egui/wgpu versions pinned (egui 0.35 / wgpu 29).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[doublegate]

Antigravity review addressed.

Suggestion — document the egui 0.35 hold in Cargo.toml. Taken, in the
commit above. The reasoning was in the commit body and the PR description, and
neither is visible to the next person editing Cargo.toml — or to the next
cargo update --aggressive, which is the realistic way this gets undone.

The comment now carries the failing error verbatim, the mechanism (egui 0.36
split DroppedFile by target — bytes_async on wasm, bytes on native — while
egui-winit's NativeFile impl provides path + bytes with no cfg gate,
so on wasm it implements a method the trait does not declare and omits the one it
does), why nothing on our side can route around it (mod dropped_file; is
unconditional in egui-winit's lib.rs, so the module compiles on wasm regardless
of our feature flags), and how to re-check it later — bump and run both wasm
clippy invocations. wgpu's 29 pin gets a line noting it is a consequence of
the egui tier rather than anything wgpu did.

Blocking issues — none found. Agreed.

[doublegate]

Both suggestions addressed.

Dependabot ignore block. Taken, and you identified the real hazard. A
comment in Cargo.toml cannot reach Dependabot, which would re-open the same
three PRs every Monday — and the risk is not the noise, it is that the twentieth
identical "bump egui from 0.35.0 to 0.36.x" gets merged on the assumption it is
routine. That is precisely how a pin with a real reason behind it gets undone.

ignore entries now cover egui, egui-wgpu, egui-winit (>=0.36) and
wgpu (>=30), carrying the failing error and the mechanism, and stating
plainly that this is a hold, not a policy — remove all four once upstream
ships the one-line cfg.

base64 0.23.1 alongside 0.22.1 vs cargo deny. Verified rather than
assumed: cargo deny check reports advisories ok, bans ok, licenses ok, sources ok. Good catch to raise — a duplicate-version failure would have shown
up only in the security workflow, which is not one of the gates I run by reflex.

[github-actions]

Antigravity review (Gemini via Ultra)

Updates the dependency graph while pinning egui and related crates to 0.35 and wgpu to 29 to prevent Dependabot from opening PRs that break the WebAssembly build.

Blocking issues

None found.

Suggestions

• Cargo.toml (line 143) & .github/dependabot.yml (line 23): The detailed technical explanation of the trait change and WASM failure is duplicated in both files. Consider moving the long write-up into a GitHub issue and replacing the comments with a brief warning and a link to that tracking issue to keep the configuration files clean.

Nitpicks

• .github/dependabot.yml (lines 39-46): Add a space after the comparison operators for standard SemVer formatting (e.g., ">= 0.36" instead of ">=0.36").
• The change is a trivial dependency bump and hold.

_{Automated first-pass review by agy on a self-hosted runner -- not a human review.}