chore(release): version hygiene — one canonical version field + drop legacy dig-companion assets

[MichaelTaylor3d]

TLDR

Two release/version-hygiene cleanups. Closes #585 #586. Minor bump 0.35.0 → 0.36.0.

#586 — one unambiguous version field

The node-info/status contract exposed BOTH version (the shipped dig-node binary / workspace version, 0.36.0) AND dig_node_version (the internal dig-node-core engine-library crate version, 0.7.0) — a different value under a second key, so a consumer couldn't tell "which version?".

Decision: version is canonical (the conventional name; what a consumer means by "the node version"). dig_node_version is removed from /version, /.well-known/dig-node.json, and control.status.

• Who reads it? Grepped the ecosystem (extension, dig-sdk, CLI, apt, updater). NOTHING external reads dig_node_version — it appeared only in dig-node's own source/docs. The extension reads version (via /ws/status). So removal is non-breaking, not a hard-break of a consumer.
• Why remove vs keep-as-alias: the two aren't the same value (so it's not a true alias), and commit (GIT_SHA) already pins the exact source of the whole workspace — including the engine, which is now an in-repo sibling crate (not the old digstore git pin) — so dig_node_version is now redundant provenance, pure ambiguity.
• SYSTEM.md: §114 documents the stable control.status contract and lists version/commit/… but NOT dig_node_version — so this field was never part of the cross-repo stable contract. No SYSTEM.md change required.

#585 — drop duplicate legacy dig-companion-* release assets

The reusable build-binaries.yml published every binary TWICE — canonical dig-node-* AND a byte-identical legacy dig-companion-* copy (dig-node was formerly dig-companion, #209). Removed the dig-companion-* staging; ship only dig-node-* (+ the dign alias).

Downstream-consumer grep (blast radius):

• apt.dig.net — PKG_dig_node_ASSET_TEMPLATE="dig-node-{ver}-linux-{arch}" (canonical). Does NOT use dig-companion-*. The workflow header comment claiming apt needed the legacy name was stale/wrong — corrected.
• dig-installer — its Repo::dig_node_legacy() fallback targets the SEPARATE DIG-Network/dig-companion repo's own frozen historical releases (owner/name/stem all dig-companion), NOT the dig-companion-* asset name inside new dig-node releases. Unaffected.
• dig-updater — no dig-companion reference.

No cross-repo coherence change needed — no repo resolves the legacy asset name from a dig-node release.

Tests (TDD, red→green)

• build_info_exposes_a_single_unambiguous_version_field (meta.rs) — asserts dig_node_version absent.
• server.rs /version test — asserts one version field, dig_node_version gone.
• release_workflow_no_longer_ships_the_legacy_dig_companion_asset (workflow-shape guard) — asserts no dist/dig-companion-* staged.

Local gate

cargo fmt --check ✓ · clippy -D warnings (dig-node-service) ✓ · service lib 190 tests ✓ · server integration 48 tests ✓ · workflow-shape + openrpc-drift guards ✓.

SemVer rationale

Minor (0.35.0 → 0.36.0): #586 is a status-contract shape change but removes an unread, non-stable-contract diagnostic field (backwards-compatible in practice — consumers read version; extension models a field subset). #585 is a chore (release-asset cleanup). No public API removed that any consumer depends on → not major.

Docs updated in the same unit

SPEC.md (§2.2, §6.2, §9 status table, §11.2 asset naming, conformance rows), README.md, USER_JOURNEY.md, runbooks/release.md.

Do NOT self-merge — orchestrator gates (#586 contract change) + merges + releases + bumps + closes.

🤖 Generated with Claude Code