ci: run the checks through yatr

[cargopete]

Makes yatr ci locally the same gate as CI, by moving the commands into yatr.toml and having the workflow call them by name.

What changed

• yatr.toml tasks now mirror this workflow's commands exactly, flag for flag. Where the existing config had drifted from CI, CI won and the config was corrected to match.
• Each wired job gains a cached yatr install, pinned via a YATR_VERSION workflow env.
• Every run: that was a check command becomes run: yatr <task>.

What deliberately did not change

Job structure, toolchains, caching actions, system dependencies, matrices and any job that was not a check pipeline are all untouched. This is a per-step substitution, not a per-job collapse, so coverage is identical.

Notes

• The yatr install clears RUSTFLAGS for that step only. yatr is a different crate and must not inherit this project's flags: a -D warnings would fail its build on any dependency warning, and a custom linker flag would fail if that linker is only installed in another job.
• The aggregate task is ci, not check, because yatr check is a builtin that validates the config file and shadows a task of that name without warning (Tasks named after builtin subcommands are listed but unreachable, silently (yatr's own check task included) cargopete/yatr#4).
• First run on a given runner pays roughly two minutes to compile yatr; after that the actions/cache entry makes it near-instant. Bumping YATR_VERSION invalidates it deliberately.

Opened as a PR rather than pushed to the default branch because a workflow change can only really be verified by CI running it. Merge once this run is green.