opc-gui: suffix Stroke::new width literals as f32 (unblocks the release)

[kyaky]

The v0.2.0-alpha.21 release build failed on macOS x86_64 only, after Linux x86_64, Linux aarch64 and macOS arm64 had all succeeded. create-release therefore never ran and no release was published.

error: falling back to `f32` as the trait bound `f32: From<f64>` is not satisfied
  --> src/theme.rs:30:60
   |
30 |     visuals.widgets.noninteractive.fg_stroke = Stroke::new(1.0, TEXT_SECONDARY);
   |                                                            ^^^ help: explicitly specify
   |                                                                the type as `f32`: `1.0_f32`
   = warning: this was previously accepted by the compiler but is being phased out;
              it will become a hard error in a future release!
   = note: for more information, see issue #154024
   = note: `-D float-literal-f32-fallback` implied by `-D warnings`
error: could not compile `opc-gui` (bin "opc-gui") due to 11 previous errors

Why

egui::Stroke::new takes width: impl Into<f32>. An unsuffixed 1.0 is {float}, and since f64: Into<f32> does not exist, rustc falls back to f32 — the behaviour rust-lang/rust#154024 is phasing out. The suffix is what was always meant; it cannot change behaviour. 11 sites, all Stroke::new(1.0, …).

Why only one job

The two macOS runners disagree on rustc:

job	rustc	lint present
macOS arm64	1.96.0 (2026-05-25)	no → passed
macOS x86_64	1.97.1 (2026-07-14)	yes → failed

Same workflow, same rust-toolchain.toml (channel = "stable"), different preinstalled toolchain — and neither is current stable (1.98.0). Worth knowing separately: release builds are not reproducible across runners today.

Second change: release builds no longer deny on warnings

actions-rust-lang/setup-rust-toolchain defaults RUSTFLAGS to -D warnings. release.yml never asked for that — there is no rustflags: key anywhere in it — it just inherited the default. That policy belongs in CI, which gates every PR. Applying it to a release build means any lint a runner happens to pick up from a newer rustc can block shipping after every artifact has already compiled, which is precisely what happened here.

rustflags: "" on the four release jobs. ci.yml keeps -D warnings on clippy and RUSTDOCFLAGS, so nothing that actually gates a change is relaxed.

Verification

Reproduced locally on rustc 1.98.0 (newer than the failing runner's 1.97.1) with a minimal case matching Stroke::new's signature — unsuffixed literal errors under -D warnings, _f32 form is silent:

fn new(width: impl Into<f32>) -> Self { ... }
Stroke::new(1.0)       // error: falling back to `f32` ...
Stroke::new(1.0_f32)   // clean

Workspace unaffected and still green: cargo test --workspace --locked → 291 passed, cargo fmt --all --check → clean, cargo clippy --workspace --all-targets -- -D warnings → clean. release.yml parses.

Every changed line is 52–84 chars, well inside rustfmt's 100, so this adds no formatting drift.

Follow-up worth doing (not in this PR)

CI never builds opc-gui. It lives outside the workspace with its own Cargo.lock, so cargo build --workspace does not reach it and cargo fmt --all -- --check does not format-check it. The GUI is compiled for the first time during a release, which is why an 11-error compile failure only surfaced at tag time. Adding

- run: cargo build --manifest-path bins/opc-gui/Cargo.toml --locked

to ci.yml (with the GTK deps the Linux runner needs) would have made this a red PR instead of a failed release. Related: bins/opc-gui/src/views.rs currently has 21 rustfmt diffs on main for the same reason — deliberately not touched here, since a whole-file reformat has no place in a PR unblocking a release.

[kyaky]

Correcting one thing I wrote in the description above, before it gets acted on.

I said a CI job could build opc-gui on Linux "with the GTK deps the Linux runner needs". That is wrong — opc-gui cannot build on Linux at all as configured. bins/opc-gui/Cargo.toml takes eframe with default-features = false and only default_fonts, glow, persistence — no x11, no wayland. I tried it locally with a full GTK stack and got:

error: The platform you're compiling for is not supported by winit
  --> winit-0.30.13/src/platform_impl/mod.rs:78:1

That is consistent with the release artifacts, which ship the GUI for macOS and Windows only. So no amount of apt packages makes a Linux GUI job work; it would need eframe's x11/wayland features added, which is a real decision about whether a Linux GUI is supported at all, not a CI tweak.

The cheap option that would actually have caught this lint is a cross-target check from the existing ubuntu runner, no new runner minutes:

- run: rustup target add x86_64-pc-windows-msvc
- run: cargo check --manifest-path bins/opc-gui/Cargo.toml --target x86_64-pc-windows-msvc --locked

float_literal_f32_fallback is a type-inference lint, so it fires during cargo check — no linking, no Windows runner. I'm verifying that this actually resolves from a Linux host before proposing it as a PR; if the Windows-target dependency graph doesn't check cleanly from Linux, the fallback is a real macOS or Windows CI job and the cost has to be weighed against how often the GUI changes.

Either way it stays out of this PR, which exists to unblock the release.