ci: SHA-pinned dtolnay/rust-toolchain is a 1.85.0 branch snapshot — masked by rust-toolchain.toml

[arcaven]

While porting the fork-friendly release-ops workflows (docs/specs/fork-friendly-release-ops.md) to a downstream fork of wirerust, the alpha build failed twice with:

error: rustc 1.85.0 is not supported by the following packages:
  wirerust@0.12.1 requires rustc 1.91

Root cause: sign-and-publish.yml and backfill-release.yml pin dtolnay/rust-toolchain@c93f4f9c67595668add93d3d6895795ce52d8c2d # stable. That SHA is a snapshot of the action's versioned branch for 1.85.0 — it hardcodes toolchain: 1.85.0 and rejects a toolchain: input (Unexpected input(s) 'toolchain', valid inputs are ['targets', 'target', 'components']).

jira-cli never notices because rust-toolchain.toml (channel = "stable") overrides the installed default at cargo invocation — the action's 1.85.0 install is dead weight and rustup fetches current stable anyway. The pin is latent, not broken: it would surface only if rust-toolchain.toml were ever removed, or in a downstream port of these workflows to a repo that lacks one (exactly how the wirerust fork hit it).

Fix applied in ArcavenAE/wirerust (8532cada): pin the action's master SHA, which requires and honors an explicit toolchain input:

uses: dtolnay/rust-toolchain@fa04a1451ff1842e2626ccb99004d0195b455a88  # master
with:
  toolchain: stable
  targets: ${{ matrix.target }}

Suggest the same change in both workflows so the pin says what it means. Low urgency — current behavior here is correct by accident thanks to rust-toolchain.toml.

Evidence: ArcavenAE/wirerust runs 29458958576 / 29459130005 (failures), 29459247861 (green after fix).