feat(cli): dign first-class alias binary for dig-node (mirror digs #434)

[MichaelTaylor3d]

What

Ship dign as a first-class alias binary for dig-node, exactly mirroring how digs aliases digstore (#434). dign <args> behaves byte-for-byte identically to dig-node <args> — same subcommands, flags, --json envelopes, and exit codes — and each binary reports its own name in --help/--version.

Superproject tracking: DIG-Network/dig_ecosystem#548.

Mechanism (mirrors digstore — a [[bin]] alias target, NOT a release-time copy)

digstore ships digs as a second [[bin]] sharing the lib entrypoint digstore_cli::run(); the release workflow builds both bins and stages the alias by string-substituting the stem. This PR replicates that exactly:

• Shared entrypoint. Lifted the CLI out of main.rs into dig_node_service::run() (new entrypoint module). Both src/main.rs and the new src/bin/dign.rs are thin shims over it — zero duplicated logic. The displayed program name is derived from arg0 (a pure, unit-tested bin_name_from_arg0 helper), so dign reports dign and dig-node reports dig-node. The service identity string stays "dig-node" (the alias renames only the invoked binary).
• Second bin target. [[bin]] name = "dign" → src/bin/dign.rs.
• Release. release.yml now builds --bin dig-node --bin dign and publishes the alias under its own stem dign-<ver>-<os_arch>[.exe] (identical shape to dig-node-<ver>-<os_arch>), alongside the existing dig-node-* + legacy dig-companion-* assets.

Blast radius (gitnexus + read-through)

The moved code (Cli/Command/PairCommand, the render_* helpers, the runtime builders) was all private to main.rs — no external consumers, confirmed by search. The change ADDS dig_node_service::run + the entrypoint module; serve/service/Config/VERSION are unchanged. No public API removed. Contained to dig-node-service.

Tests

• tests/cli_dign_alias.rs — alias-identity against the REAL built binaries: same --version semver (each leading with its own name), dign --help usage reads dign (not dig-node), dign status --json produces the identical NOT_SERVING (exit 1) envelope with service:"dig-node", and an unknown subcommand fails identically under both.
• tests/release_workflow_dign_guard.rs — guard that release.yml builds --bin dign and stages the dign-<ver>-<os_arch> asset (protects the published-asset contract; producer-side counterpart to the installer's future Repo::dign()).
• entrypoint unit tests — the arg0 → program-name rule (stem, .exe strip, empty/absent fallback to dig-node) + Cli::command().debug_assert().

Verified locally: cargo fmt --all clean, cargo clippy --all-targets --locked -- -D warnings clean, the new + existing CLI tests green.

Version

Minor bump 0.30.0 → 0.31.0 (feat: new backwards-compatible capability; no existing behaviour changed). Root Cargo.toml + Cargo.lock synced for --locked.

Out of scope (follow-up, gated on this release)

• dig-installer Repo::dign() + install-alongside (#548 step 3).
• SYSTEM.md dign ≡ dig-node entry (orchestrator-owned) + docs.dig.net dign mention (mirroring the existing digs entries).

Refs #548

🤖 Generated with Claude Code