ci: make the Makefile the single source of truth for build operations

[mimi-esc]

Closes #266

Summary

The repo defined build operations twice — the Makefile and .github/workflows/ci.yml — with CI invoking cargo directly and never touching wasm:. This PR makes the Makefile the single source of truth: CI now invokes make fmt-check, make build, and make test, so a contributor and CI run byte-identical commands, and any future change to a build step lands in one place and applies to both. No operation's behaviour changed.

Operation-by-operation comparison (before)

Operation	Makefile	CI (before)	Divergence
Format check	make fmt-check → cargo fmt --all -- --check	cargo fmt --all -- --check	Same command defined in two places
Build	make build → cargo build	cargo build	Same command defined in two places
Test	make test → cargo test	cargo test	Same command defined in two places
Format (in place)	make fmt → cargo fmt --all	—	Local-only; undocumented
Wasm	make wasm → cargo build --target wasm32-unknown-unknown --release	—	Never run in CI (tracked separately); undocumented
Clean	make clean → cargo clean	—	Local-only; undocumented
Toolchain	none (default toolchain)	dtolnay/rust-toolchain@stable	CI pinned stable; local un-pinned

Divergences found

1. CI and the Makefile both defined fmt-check/build/test with identical commands — two definitions of the same operations that can silently drift.
2. wasm: existed only in the Makefile and was never run by CI, so the deployment artifact was never built in CI (the issue's headline symptom). Wiring wasm into CI is tracked separately; this PR only documents it and does not conflict with that follow-up (it lands as a one-line make wasm step).
3. fmt and clean were local-only Makefile targets with no documentation.
4. rust-toolchain.toml does not exist, contrary to the issue's context ("rust-toolchain.toml pins the toolchain"). CI pinned stable via the dtolnay action; locally the toolchain was whatever the contributor's default was. This PR adds rust-toolchain.toml (channel = "stable") so both paths respect the same pin.

Decision: the Makefile is the single source of truth; CI calls make

• One executable definition. make <target> locally and in CI is the same command. If someone improves a build step — adds a flag, a feature, a target — they edit the Makefile once and CI picks it up automatically, closing exactly the drift this issue describes.
• make is available on the runner. It ships preinstalled on ubuntu-latest GitHub runners.
• Failures propagate. Every recipe is a single command line (no - prefix, no || true, no multi-line shell), so make aborts on the first nonzero exit and returns nonzero — verified locally (below). GitHub Actions fails a step on any nonzero exit, so a failing recipe fails the job.
• The alternative — deleting the Makefile and documenting raw cargo invocations — is defensible, but it would leave the long wasm incantation to be typed by hand and give future build-step changes two landing spots (CI and README) that could drift again. Keeping the Makefile gives future changes a single landing spot.

Parity after this change

Operation	Local	CI	Parity
Format check	make fmt-check	make fmt-check	identical
Build	make build	make build	identical
Test	make test	make test	identical
Format (in place)	make fmt	local convenience	documented
Wasm	make wasm	not wired yet (separate issue)	documented; no conflict — the follow-up lands it as one make wasm step
Clean	make clean	local convenience	documented
Toolchain	rust-toolchain.toml (stable)	dtolnay/rust-toolchain@stable	identical

The README's Commands section now documents every target and notes which ones CI runs; the Setup and Contributing sections use the same make targets.

Failure-propagation evidence

Make aborts on a failing recipe and returns nonzero — demonstrated locally by running make build in an environment without cargo:

$ make build
cargo build
make: cargo: No such file or directory
make: *** [Makefile:10: build] Error 127
$ echo $?
2

Each CI step is a single make <target> invocation, and GitHub Actions marks the step (and job) failed on any nonzero exit, so a failing recipe cannot be swallowed. I did not push a deliberately broken commit to this PR branch to produce a failing Actions run; the propagation mechanism above is guaranteed by make's semantics (single-line recipes, no error suppression) and was verified locally. The passing CI run for this PR (linked below once complete) is the "everything green" proof.

Verification

• make fmt-check, make build, make test, make wasm, cargo test — CI runs make fmt-check / make build / make test on this PR.
• A Rust toolchain was not available in my local environment; the CI run on this PR is the authoritative pass. Note the wasm build also has a pre-existing, separately-tracked toolchain issue (error[E0152]: duplicate lang item … panic_impl, documented in test_snapshots/test/FIX_REPORT.md) unrelated to this change.
• No operation's behaviour changed: recipes and their underlying cargo invocations are byte-identical to before.