A minimal rustup profile, and a suite whose failures move around

A minimal rustup profile, and a suite whose failures move around Two more things the first CI runs found, both about the gates rather than the code. **mise installs rust with rustup's minimal profile.** No `cargo-fmt`, no `cargo-clippy`, so pinning the lint job to the same toolchain as everything else broke it: "'cargo-fmt' is not installed for the toolchain '1.94.0'". A laptop never sees this — rustup put the components there during some earlier install and they stay — which is exactly the class of difference between a developer machine and a fresh runner that a pinned toolchain is supposed to remove. `.mise.toml` now names the components beside the version, and the job adds them explicitly from `mise current rust` as well, so it does not depend on which mise version the runner happens to ship. **The browser suite is flaky, and it was flaky before any of this.** Three full runs and no test failed in more than one of them: unchanged `main` lost 4 of 410, a branch touching no frontend code lost 3, and the same branch serialised lost 1. Every one a `toBeVisible` or `toContainText` timeout in an unrelated spec — timing, not a broken assertion — and `--workers=1` improving it without curing it rules out worker contention as the whole story. `browse.e2e.ts` is in all three lists. Retries under CI are instrumentation, not a cure: a test that passes on a second attempt is reported as flaky and the build goes green, and one that fails three times is worth reading. Without them the first CI run a reader ever sees is red for a reason indistinguishable from "the tests do not pass". The debt is written down in TASKS.md, pointed at `browse.e2e.ts`, rather than left in a retry count for somebody to find later.