ci: pin dig-dns version to 0.15.1

[MichaelTaylor3d]

Summary

Updates dig-dns version pin from 0.9.1 to 0.15.1 in the installer e2e workflow.

The v0.9.1 release does not include the digd binary, which is required by the installer's default component set (verified in the test at line 1127). The v0.15.1 release includes both dig-dns and digd binaries.

Asset comparison

v0.9.1 assets:

• dig-dns-0.9.1-linux-x64
• dig-dns-0.9.1-macos-arm64
• dig-dns-0.9.1-macos-x64
• dig-dns-0.9.1-windows-x64.exe

v0.15.1 assets:

• digd-0.15.1-linux-x64
• digd-0.15.1-macos-arm64
• digd-0.15.1-macos-x64
• digd-0.15.1-windows-x64.exe
• dig-dns-0.15.1-linux-x64
• dig-dns-0.15.1-macos-arm64
• dig-dns-0.15.1-macos-x64
• dig-dns-0.15.1-windows-x64.exe
• (plus .deb, .msi, .pkg, .wixpdb packages)

Filename construction compatibility

The installer's release.rs uses the stem "digd" to match assets named digd-<ver>-<os_arch>[.exe]. Both v0.9.1 and v0.15.1 use matching conventions, but v0.9.1 has no digd assets while v0.15.1 does.

Previous workflow status

The e2e test (line 1127) explicitly checks for the presence of a digd binary in the default plan, making v0.9.1 a non-passing pin for the current test suite. This update restores a working pin.

Closes https://github.com/DIG-Network/dig_ecosystem/issues/2796

[MichaelTaylor3d]

Correcting this PR's stated justification — the fix is right, the reasoning in the description is not

The description says the v0.9.1 pin was non-working and that the e2e "would error on the hard count
check". Measured: the installer-e2e has been passing — runs 31855214292 (Aug 15) and
31829541660 (Aug 14) both success.

The reason is visible at installer-e2e.yml:1289: the check that wants digd runs

sudo -H ./target/release/dig-installer --dry-run --json > planned.json

It asserts the PLAN, not a download. digd appears in the default component set regardless of
whether the pinned dig-dns release actually carries that asset, because a dry run fetches nothing. So the
stale pin never tripped this check.

The fix is still correct, for the original reason rather than the claimed one

The pin carries a deliberate rationale at installer-e2e.yml:25-29:

"DIG_DNS_VERSION is pinned to 0.9.1, NOT the newer 0.10.x tags: dig-dns's own release pipeline has been
failing to publish a GitHub Release for those… 0.9.1 is the last tag with real, downloadable assets."

That was true when written. It is not true now:

• dig_ecosystem#525 — the very blocker cited — is CLOSED. The dig-dns release pipeline is fixed.
• v0.9.1: 4 assets, no digd. v0.15.1: 13 assets including digd-0.15.1-*, plus .deb, .msi, .pkg.

So this is a stale deliberate pin, not a broken one — and the comment explaining it must be updated
too, or the next reader re-derives a rationale that no longer holds.

The secondary finding, which is the more useful one

The e2e cannot catch this class. Its default-component check asserts what the installer plans to
install; it never proves the planned asset is fetchable at the pinned version. A pin pointing at a
release with a missing binary passes it silently.

That is worth its own ticket in dig-installer rather than expanding this PR — but it should be recorded,
because "the e2e is green" was the reason nobody noticed six minors of drift.

[MichaelTaylor3d]

Gate: PASS (single correctness gate — mechanical, behaviour-preserving)

Tier per §1.10: this is a workflow env pin plus a lockfile re-lock. No custody, crypto, or wire surface, so one correctness gate rather than the triple.

The pin is correct, measured against the actual releases

release	assets	ships digd
v0.9.1	4	no
v0.15.1	13	yes — linux-x64, macos-arm64, macos-x64, windows-x64

The old pin's own comment cited dig_ecosystem#525 as the reason to stay on 0.9.1; that issue is closed, and 0.9.1 genuinely has no digd for the installer's default component set to place.

Why five gui * jobs were red, and what fixed it

The 0.44.0 → 0.44.1 bump updated the root Cargo.lock but not gui/app/src-tauri/Cargo.lock, which carries its own dig-installer entry. Every gui * job runs cargo with --locked against that second workspace, so all five failed identically:

error: cannot update the lock file .../gui/app/src-tauri/Cargo.lock
because --locked was passed to prevent this

Fixed in 8b1f3ee, verified with cargo metadata --manifest-path gui/app/src-tauri/Cargo.toml --locked resolving offline. gui clippy and gui build (macos-14) are green again.

Checked and deliberately left alone

The v0.9.1 strings in src/lib.rs (:960, :1671, :6001-6020) are regression fixtures that exist to prove the installer handles an old release with no digd asset. They must keep naming 0.9.1; they are not drift.

Secondary finding — logged here rather than ticketed

The e2e cannot catch this class of drift at all. It drives --dry-run --json and asserts the component plan — an exact count plus per-component membership — so it verifies what the installer intends to place and never that the planned asset is fetchable at the pinned version. That is why this pin could sit six minors stale behind a green suite. It is test-coverage work with no user-visible surface, so per §1.3c rule 1 it stays a comment here rather than becoming a new issue.