build: add a fast test profile to cut edit-test iteration

[inureyes]

Summary

Add [profile.test-fast] to Cargo.toml plus Makefile and doc support so local and agent edit-test iteration no longer pays the [profile.release] fat-LTO + codegen-units = 1 cost, which is measured at 4 to 6 minutes per incremental rebuild of the ~390k-line main crate today.

What changed

• Cargo.toml: new [profile.test-fast] (inherits = "release", lto = "thin", codegen-units = 16, strip = false, incremental = true, opt-level = 3 kept), with a comment explaining why it exists and when not to use it, mirroring the [profile.release] comment style.
• Makefile: new test-fast (platform-aware, mirrors release/RELEASE_FEATURE_FLAG), test-fast-cuda (mirrors release-cuda, explicit --features cuda), and check-fast targets, all wrapping cargo test/cargo check --profile test-fast; a FILTER variable for narrowing runs; a make help example line.
• docs/installation.md: new "Fast iteration builds" subsection explaining the tradeoff and giving make test-fast / make test-fast-cuda / FILTER= usage.
• CONTRIBUTING.md: points contributors at test-fast for iteration in the existing build/test step, while keeping the --release commands as the pre-PR gate.

Why lto = "thin" and not false

The workspace is split across crates (mlxcel, mlxcel-core, mlxcel-surgery), and the hot MLX FFI call sites cross that mlxcel / mlxcel-core boundary. lto = "thin" keeps cross-crate inlining there while dropping the whole-program fat-LTO link that dominates release build time; lto = false would wall off that boundary from inlining entirely. The measured incremental number below already lands well inside the "seconds, not minutes" target with thin LTO, so there was no measured case for dropping further to false and risking a numerics regression in MLX-heavy tests.

Measured timings (this session, Linux/CUDA, CARGO_TARGET_DIR pointed at the shared target dir)

• Cold build (cargo test --profile test-fast --features cuda --lib -- models::minimax_m3 server::chat_request, all ~439 deps plus the MLX CUDA C++ tree compiled under the new profile for the first time): 293s (4m53s) wall clock, 343 crates compiled.
• Incremental rebuild (touch src/server/chat_request.rs, same narrow test target): 19s wall clock (17.46s of that is the cargo compile step itself).
• Baseline for comparison: today's [profile.release] incremental rebuild of the same crate is measured at 4 to 6 minutes (240 to 360s).
• Incremental speedup: roughly 13x to 19x, well above the 3 to 5x expected in the issue.

Parity check

Ran the representative narrow test set from the issue under test-fast and compared against today's release-profile pass counts (recorded from today's implementation chain runs on the same code at main 80a05f9, not rerun here to avoid clobbering a busy shared build directory):

• cargo test --profile test-fast --features cuda --lib -- models::minimax_m3 server::chat_request: 78 passed, 0 failed (10 minimax_m3 + 68 chat_request), matching the release-profile counts.
• cargo test --profile test-fast --features cuda -p mlxcel-core -- sampling cache::ring: 61 passed, 0 failed (57 sampling + 4 cache::ring), matching the release-profile counts.

Test plan

• cargo test --profile test-fast --features cuda --lib -- models::minimax_m3 server::chat_request (78 passed, 0 failed)
• cargo test --profile test-fast --features cuda -p mlxcel-core -- sampling cache::ring (61 passed, 0 failed)
• Cold and incremental timings recorded above
• No .rs files touched, so cargo fmt --all -- --check is not applicable to this change

Closes #809