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

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

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

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,
`bstr`, `camino`, `clang-sys`, `darling`, `either` and the rest. Plus
`taiki-e/install-action` v2.85.10 -> v2.85.13 at both call sites in
`security.yml` (#387).

DECLINED, with the reason established by experiment: egui / egui-wgpu /
egui-winit 0.35 -> 0.36.1 (#389, #390, #391). `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 made
`DroppedFile` a trait and split it by target: `bytes_async` on wasm (files
can only be read asynchronously in a browser), `bytes` on native. Upstream
issue #8354, now closed, is the change that introduced it. `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` — not feature-gated, not
target-gated — so the module compiles on wasm whatever we do, and the fix
belongs upstream (a one-line cfg on the module and its `use`). 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 silently
goes stale — and the useful output of re-checking is the specific method
name a future attempt needs, `bytes_async`, rather than a bare verdict.

Verified: workspace clippy, all four native feature combinations plus
`full`, BOTH wasm32 targets, rustdoc with warnings denied, the `no_std`
cross-build, 124 workspace test binaries, and `cargo deny check`
(advisories ok, bans ok, licenses ok, sources ok).

* docs(deps): record the egui 0.35 hold where the pin lives

Review suggestion, taken. The reason egui / egui-wgpu / egui-winit are held at
0.35 was in the commit body and the PR — neither of which anyone reads while
editing `Cargo.toml`, which is exactly where the next person (or the next
`cargo update --aggressive`) will decide to move them.

The comment carries the failing error verbatim, the mechanism (egui 0.36 split
`DroppedFile` by target — `bytes_async` on wasm, `bytes` on native — and
`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`), and how to re-check: bump it and run
both wasm clippy invocations. `wgpu`'s 29 pin gets a line saying it is a
consequence of the egui tier rather than anything wgpu did.

No dependency change; comments only.

* chore(deps): hold the egui tier in dependabot.yml, not only in a comment

Review made the point that matters: a comment in `Cargo.toml` explains why the
pin exists, and Dependabot cannot read it. It would keep re-opening the same
three PRs every Monday.

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 -- which is exactly
how a pin with a real reason behind it gets undone.

`ignore` entries for egui, egui-wgpu, egui-winit (`>=0.36`) and wgpu (`>=30`),
carrying the failing error and the mechanism, and saying plainly that this is a
HOLD and not a policy: remove all four once upstream ships the one-line cfg, and
re-check by bumping and running both wasm clippy invocations.

Also raised: whether the `ureq` update pulling in `base64` 0.23.1 alongside the
existing 0.22.1 would trip `cargo deny`'s duplicate-version check. Verified
rather than assumed -- `cargo deny check` reports `advisories ok, bans ok,
licenses ok, sources ok`.

Author: doublegate

.github/dependabot.yml

@@ -20,6 +20,32 @@ updates:
       - "doublegate"
     assignees:
       - "doublegate"
+    # HOLD the egui tier. A comment in `Cargo.toml` explains WHY the pin exists,
+    # but a comment does not reach Dependabot -- it would keep re-opening the
+    # same three PRs every Monday, and the risk is not the noise, it is that the
+    # twentieth identical PR gets merged on the assumption it is routine.
+    #
+    # `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 0.36 split `DroppedFile` by target (`bytes_async` on wasm, `bytes` on
+    # native) while egui-winit's `NativeFile` impl has no cfg gate, so on wasm it
+    # implements a method the trait does not declare and omits the one it does.
+    # `wgpu` is held with them only because `egui-wgpu` 0.35 pins it.
+    #
+    # REMOVE ALL FOUR ENTRIES once upstream ships the fix -- this is a hold, not
+    # a policy. Re-check by bumping and running both wasm clippy invocations.
+    ignore:
+      - dependency-name: "egui"
+        versions: [">=0.36"]
+      - dependency-name: "egui-wgpu"
+        versions: [">=0.36"]
+      - dependency-name: "egui-winit"
+        versions: [">=0.36"]
+      - dependency-name: "wgpu"
+        versions: [">=30"]
     # Group minor and patch updates together
     groups:
       development-dependencies:

.github/workflows/security.yml

@@ -60,7 +60,7 @@ jobs:
       # cargo-audit release needs >= 1.88 to COMPILE. The prebuilt binary RUNS
       # fine under any toolchain — it only parses Cargo.lock, it never compiles
       # the project — so the toolchain pin is irrelevant to it.
-      - uses: taiki-e/install-action@v2.85.10
+      - uses: taiki-e/install-action@v2.85.13
         with:
           tool: cargo-audit
       - run: cargo audit
@@ -75,7 +75,7 @@ jobs:
       # Prebuilt binary for the same reason as the audit job: the latest
       # cargo-deny needs rustc >= 1.88 to build from source, while the repo is
       # pinned to 1.96. Policy lives in `deny.toml`.
-      - uses: taiki-e/install-action@v2.85.10
+      - uses: taiki-e/install-action@v2.85.13
         with:
           tool: cargo-deny
       - run: cargo deny check