fix(makefile): repair make slimest on current nightly

[ArthurZucker]

Stacked on #2119 (feat/train_encode_split), which is where make slimest lives — main has no such target, hence the base.

The bug

make slimest does not build on a current nightly:

error: panic_immediate_abort is now a real panic strategy! Enable it with `panic =
"immediate-abort"` in Cargo.toml, or with the compiler flags `-Zunstable-options
-Cpanic=immediate-abort`. In both cases, you still need to build core, e.g. with `-Zbuild-std`
error: could not compile `core` (lib) due to 1 previous error

panic_immediate_abort stopped being a -Z build-std-features value and became a real panic strategy. The target only worked on a nightly predating the rename, so whether make slimest builds depended on how stale your nightly alias happened to be.

The fix

• Drop the dead -Z build-std-features=panic_immediate_abort.
• Pass the strategy as a codegen flag: RUSTFLAGS="-Zunstable-options -Cpanic=immediate-abort", applied inline on the slimest recipe only.
• Add NIGHTLY ?= nightly so a stale default alias can be bypassed without editing the Makefile (make slimest NIGHTLY=nightly-2026-04-28), and so CI can pin.

Deliberately not panic = "immediate-abort" in [profile.slimest], which the error message also offers: a profile value stable cargo cannot parse would break every cargo command in the workspace — make build, make test, cargo metadata, CI on stable — not just this one target. The tradeoff is that the recipe replaces any ambient RUSTFLAGS; that is noted in the comment.

Size

BPE-only, tk-serialize --example binsize_pipeline, --no-default-features --features bpe,deserialize, aarch64-apple-darwin:

Build	Toolchain	Raw (stripped)	Gzipped
slim (minsize)	stable 1.97.0	636,944	332,799
slim (minsize)	nightly 1.97.0	636,960	333,449
--profile slimest, no -Z	stable 1.97.0	636,944	332,799
slimest, old flag	nightly 1.89	370,512	201,047
slimest, this change	nightly 1.97.0	353,840	190,690

−42.7% gzipped vs slim (332,799 → 190,690). The 10,357 B improvement over the old flag path is the newer compiler, not the flag change.

Two things the numbers settle, since both have caused misreadings before:

• Nightly by itself buys nothing — +650 B at equal compiler version. The entire win is build-std + immediate-abort, so the nightly requirement is unavoidable rather than incidental. (An earlier apparent "+4.6% on nightly" was purely a 13-month-old nightly, not nightly.)
• Row 3 is byte-identical to row 1, confirming the existing comment that --profile slimest without the -Z flags is minsize under a different directory name.

Verification

• make slimest-size NIGHTLY=nightly-2026-04-28 → slimest tk-encode: 190690 bytes gzipped, rc=0.
• Produced binary contains 0 occurrences of panicked at, backtrace, RUST_BACKTRACE (vs 2/12/3 in slim), so the panic strategy really applied rather than silently no-opping.
• make -n slim-size emits a byte-identical command to before; that target is untouched.
• On a too-old nightly the target now fails loudly (rc=2) instead of producing a wrong-size binary.

Note for anyone building this: rustup update nightly if make slimest fails on the panic strategy. Verified good on 1.97.0-nightly (2026-04-27); 1.89.0-nightly (2025-06-22) is too old. I did not add version detection to support both spellings — two code paths to keep a 13-month-old nightly working seemed worse than one clear error plus the comment, but happy to add it if you disagree.

[ArthurZucker]

Folded into #2119 directly: the fix now sits on feat/train_encode_split itself (c275f26), so this stacked PR is empty.