ci: pin rust-toolchain action to @v1 and pass toolchain: 1.84.1 explicitly

[Senorespecial]

Summary

Decouples dtolnay/rust-toolchain action version from Rust toolchain version. The action reference changes from dtolnay/rust-toolchain@1.84.1 (single fully-qualified ref) to dtolnay/rust-toolchain@v1 with with: toolchain: 1.84.1 (major-version tag + explicit toolchain input). The Rust toolchain is still effectively pinned to 1.84.1, matching rust-toolchain.toml's channel = "1.84.1".

Why

1. Action upgrades vs toolchain upgrades: a future bump of the action (@v1 -> @v2) is now decoupled from a future bump of Rust (1.84.1 -> 1.85). Today they're tangled in a single string.
2. cargo install channel-name leak: when the action was called with dtolnay/rust-toolchain@1.84.1 and the job depended on rustup's default channel-name derivation semantics, downstream calls like cargo install cargo-audit could end up resolving against stable-x86_64-pc-windows-msvc on an ubuntu runner, surfacing as error: target tuple in channel name 'stable-x86_64-pc-windows-msvc'. With the explicit with.toolchain: 1.84.1 input, rustup always re-derives the host triple (1.84.1-x86_64-unknown-linux-gnu on Linux, -apple-darwin on macOS, -pc-windows-msvc on Windows) and cargo install accepts it.

Closes #33.

Diff

       - name: Install Rust toolchain
-        uses: dtolnay/rust-toolchain@1.84.1
+        # Pin the action to its major-version tag and pass the Rust toolchain version
+        # explicitly via `with.toolchain`. Decouples action upgrades from toolchain
+        # version pinning. The explicit `toolchain: 1.84.1` input matches the project's
+        # already-pinned `rust-toolchain.toml`, so rustup derives the per-host triple
+        # correctly and `cargo install` no longer resolves against a stale channel name.
+        # See Octo-Protocol-org/Octo-Protocol#33.
+        uses: dtolnay/rust-toolchain@v1
         with:
+          toolchain: 1.84.1
           components: rustfmt, clippy

What is intentionally NOT touched

• rust-toolchain.toml -- its channel = "1.84.1" is already correct and matches with.toolchain on the runner. The repo-level pin is unchanged.
• Swatinem/rust-cache@v2 -- the cache action interoperates with the rust-toolchain action unchanged.
• The deny / audit / secret-scan jobs -- they're already wired with first-party actions (EmbarkStudios/cargo-deny-action@v2, rustsec/audit-check@v2, gitleaks/gitleaks-action@v2) and don't need this.

Acceptance criteria

• cargo install cargo-audit on ubuntu-latest no longer errors with target tuple in channel name 'stable-x86_64-pc-windows-msvc'.
• rustup show active-toolchain on a runner says 1.84.1-x86_64-unknown-linux-gnu (or the matching per-runner host triple).
• All four CI jobs (fmt · clippy · test, cargo-deny, cargo-audit, gitleaks) flip from failure to success on the next run.
• PR ci: enforce --locked on workspace cargo invocations #34's CI status flips to "all green" once retried, since ci: enforce --locked on workspace cargo invocations #34 depends only on Cargo.lock parity (a separate concern).

Cross-links (in order)

• PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 -- Senorespecial/Octo-Protocol -> Octo-Protocol-org/Octo-Protocol: feat(dashboard): add gas sponsorship status indicator to wallet cards (feat(dashboard): Add gas sponsorship status indicator to wallet cards on the dashboard home #14)
• api: surface fees_spent_today_stroops in GET /v1/wallets/:id/sponsorship so dashboard consumption bar can render #32 -- api: surface fees_spent_today_stroops in GET /v1/wallets/:id/sponsorship
• PR ci: enforce --locked on workspace cargo invocations #34 -- ci: enforce --locked on workspace cargo invocations
• ci: install of cargo-audit errors out with stable-x86_64-pc-windows-msvc on ubuntu-latest — wire rust-toolchain channel for runners to stable-x86_64-unknown-linux-gnu #33 -- ci: install of cargo-audit errors out with stable-x86_64-pc-windows-msvc on ubuntu-latest