fix: unbreak tag releases after the dependabot batch, correct MSRV, drop unused indicatif

[krassx]

Follow-up to the seven dependabot PRs (#1, #3–#8) that landed on main. One of
them broke the release pipeline in a way that would not have surfaced until the
next tag push. Two other issues turned up while validating.

1. Tag releases were broken (the urgent one)

The github-actions PR (#1) hand-edited six actions/checkout@v6 → @v7 lines
inside .github/workflows/release.yml. That file is generated by cargo-dist,
and the plan job verifies it against the generator — so dist plan has been
failing on main since the merge.

This was not just a red check. plan is also the first job of the real release
workflow, so the next vX.Y.Z tag push would have failed before building a
single artefact.

There is no upgrade path out of it: cargo-dist 0.32.0 (the pinned version) is
the latest published release on both crates.io and upstream GitHub, and no
released version emits checkout@v7. The fix is to regenerate — dist generate
reverts exactly those six lines and nothing else.

The @v7 bumps in the five hand-written workflows are untouched and correct.

Dependabot cannot be told to skip a single file, so it will keep proposing this
every week; the trap is now documented in dependabot.yml for the next reviewer.

2. rust-version = "1.79" was false

Predates this batch. Verified empirically, not by inference:

toolchain	result
cargo +1.88 check --all-targets	succeeds
cargo +1.86	fails — gimli, globset require 1.88
cargo +1.85	fails — same, plus icu_* at 1.86

Nothing catches this drift: rust-toolchain.toml selects stable, not the MSRV,
and every CI job builds stable too. A routine bump can raise the real floor
while the declared one stays put.

With the floor accurate, cargo enforces it — cargo +1.86 now fails with
bugsee-cli@0.7.4 requires rustc 1.88 rather than producing a binary claiming
support for a toolchain it cannot build on.

CLAUDE.md said "MSRV 1.79 (pinned via rust-toolchain.toml)" — wrong twice
over, both the version and the pinning claim. Corrected.

3. Dropped unused indicatif

Referenced nowhere. Confirmed three ways: repo-wide case-insensitive search hits
only the Cargo.toml line itself; a search for every public API symbol it
exposes (ProgressBar, ProgressStyle, MultiProgress, ProgressDrawTarget,
HumanBytes, HumanDuration, ProgressIterator, …) returns nothing; and
cargo check --all-targets compiles clean without it.

PR #6 was a no-op 0.17 → 0.18 bump on code we never call. Prunes 6 crates from
the lock: indicatif, console, encode_unicode, portable-atomic,
unicode-width, unit-prefix.

Validation

Every CI job replicated locally, matching the workflows exactly — including the
global RUSTFLAGS: "-D warnings" and cargo test --all-targets:

job	result
ci.yml / rustfmt	exit 0
ci.yml / clippy	exit 0
ci.yml / test	exit 0 — 455 passed, 0 failed
e2e.yml	exit 0 — 17/17 flows PASS
release.yml / plan	exit 0 — full plan for all 5 triples

npm-publish.yml, mirror-to-s3.yml, and windows-e2e.yml are workflow_dispatch
against a published tag and need AWS/npm credentials — not locally runnable, not
affected.

Wire format is unchanged. Since the batch included zip 2.4.2 → 7.2.0, I
packed an artefact + mapping with this branch's binary and compared against the
archive produced by e7de272 (pre-dependabot): byte-identical — same entry
names, method 0 stored for the artefact, method 93 (Z_STANDARD) for mapping.txt,
same fixed 1980-01-01 mtime, extract-version, and flag bits.

Not included

docs/unity-il2cpp-linenumber-mappings.md has unrelated in-progress edits in the
working tree; deliberately left out of this branch.

🤖 Generated with Claude Code