feat(cli): add first-class digs alias binary for digstore

[MichaelTaylor3d]

TLDR

digs <args> now behaves identically to digstore <args> — a first-class installed alias binary (not a shell alias), shipped alongside digstore everywhere. Closes DIG-Network/dig_ecosystem#434.

What changed

• Second [[bin]] digs target in crates/digstore-cli/Cargo.toml, sharing ONE codepath: main()'s body was extracted into digstore_cli::run(); src/main.rs and the new src/bin/digs.rs are thin shims over it (DRY — no duplicated logic).
• Invoked-name is first-class: run() parses argv with the invoked binary's name (arg0 file-stem, via the new invoked_bin_name()) as clap's program + bin name, so digs --help/--version/errors read digs — not a hardcoded digstore, and not the raw absolute arg0 path.
• completion + --help-json emit the invoked name too: digs completion <shell> binds completions to digs, and digs --help-json reports "name":"digs".
• release.yml (the tag-driven per-OS GitHub Release workflow the installer + apt consume) builds + publishes digs beside digstore in BOTH asset shapes: bare per-OS binaries (digs-<ver>-<os>-<arch> for dig-installer's RawBinary matcher) and the linux .tar.gz (now carrying both digstore + digs at root, for apt's .deb).
• SPEC.md documents the alias; new integration suite tests/cli_digs_alias.rs proves parity.

Note on scope: human-facing example/hint text (after_help blocks, "next: digstore …" hints) intentionally keeps the canonical digstore name — those commands work verbatim under digs since the surface is identical, and rewriting every hint to be dynamic would thread the bin-name through the whole output layer for no behavioral gain. publish-binary.yml is untouched: it is the hub compile-worker S3 sync (needs only digstore compile), not the per-OS release-asset workflow.

How verified (this session, Windows + short CARGO_TARGET_DIR)

• fmt cargo fmt -p digstore-cli -- --check clean; clippy cargo clippy -p digstore-cli --all-targets -- -D warnings clean.
• Full suite green: cargo test -p digstore-cli — 271 lib unit tests + every integration suite pass, 0 failures (the main→run() refactor is behavior-preserving).
• New alias suite (6 tests) green: version parity (digs 0.13.0 vs digstore 0.13.0, same semver), Usage: digs, byte-identical --help-json command tree/globals/exit-codes (only name differs), digs completion bash contains zero digstore references, and digs --json status → identical NO_STORE/exit-3 envelope.
• §3.5 installed-binary: cargo install --path crates/digstore-cli --force --locked produced BOTH ~/.cargo/bin/digstore.exe and digs.exe (identical 32,075,776 bytes); digs --version == digstore --version semver; and a real init → add → commit → log → status flow completed under the installed digs (produced a real capsule).

Blast radius (gitnexus)

impact on the touched entrypoint symbols is LOW: print_help_json is called only from the main flow; completion::run has no symbol-level upstream. detect_changes confirms the changed symbols are exactly main, completion::run, print_help_json + the two docs — the 9 "affected processes" are all the Main → X entry flows, unchanged in behavior (verified by the green suite).

Version bump

0.12.0 → 0.13.0 (minor): a new, backwards-compatible capability (a new binary), no change to existing digstore behavior.