feat(mirror): prove the mirror-coin lifecycle on a real machine

[MichaelTaylor3d]

DRAFT — gate round has not returned. Do not merge.

Outcome: the measurement was taken, and the news is good

The step-7 mirror lifecycle works end to end on a real machine. Built from 9eb8fbd (0.179.0)
in this lane's own worktree, run with RUST_LOG=mirror=debug on port 9779:

{"ok":true,"action":"mirror","service":"dig-node","version":"0.179.0","state":"known","entries":[],"complete":true,"cursor":null,"locked_dig_base_units":0,"epoch":104}

INFO  mirror: the mirror lifecycle is live: this node may create and reclaim collateral
DEBUG mirror: mirror pass complete epoch=104 bonds=0 locked_dig_base_units=0 reclaimed=0 created=0

state: "known" — the pass ran, read chain, and published. None of the five chain_unreadable
rows is in force. #433's headline was an artifact of the measured binary (0.172.0 = 6e8bfa7)
predating step 7 (5df3e34), now confirmed in the affirmative direction rather than only argued
from commit ancestry. Full reading: #433 (comment)

What this PR contains

One DEVELOPMENT_LOG.md entry and a patch version bump. No behaviour changes, because the
measurement showed there is nothing to fix on the path that was suspect.

The entry exists because three of the facts cost a full build to re-derive: a chain_unreadable
reading is only evidence about the binary that produced it; entries: [] under state: "known" is
a truth rather than a fabricated zero; and chain_unreadable is today the catch-all for five
structurally different states, two of them terminal.

Blast radius

Zero. No symbol is edited — the diff is DEVELOPMENT_LOG.md plus the version field in the
workspace Cargo.toml. No impact query was required because nothing is renamed, removed, or
called differently. (Recorded rather than skipped silently: the registered gitnexus index for this
repo is ~301 commits stale, so it could not have answered a call-graph question here anyway.)

What is bounded and LEFT, not implied

• mirror bond-states answers chain_unreadable on a synced node with 8 peers, while balances read fine #433 stays OPEN for its remaining content only: rows 1-3 cannot be named by
  MirrorBondStatesUnknownReason, so a node in one of them would still say chain_unreadable while
  its chain reads work. Latent, not active — no configuration measured today reaches it. Fixing it
  is a release-first change in dig-node-control-interface (currently 0.27.0), not a dig-node edit.
• Mirror-coin lifecycle: the pass runner, the state surface, the DHT pointer, and the real-machine proof #412 step 8 and the automated-spend record has a production writer that can now fire — needs a real cycle to prove a row #411 stay OPEN, blocked on the same TWO independent things: this node caches
  zero capsules, so there is no (store, root) to bond; and it has no publishable advertise URL
  (Mirror creates need an advertised URL this node can be fetched at #426). An invented URL is not a workaround — the value is written to chain as a claim about
  where this node can be fetched.

Refs #433, #412, #411

[MichaelTaylor3d]

Parked, not abandoned — and deliberately queued behind PR #442

Reconciled by the 07:14Z wake. The lane that opened this PR is gone (its session ended); this comment
records the decision so the next reader does not re-derive it.

This PR is worth landing

It is documentation only — DEVELOPMENT_LOG.md, CHANGELOG.md, and the version line. No code.
Its three recorded realizations are still true and still load-bearing:

• a chain_unreadable reading is only evidence about the binary that produced it, which is how
  mirror bond-states answers chain_unreadable on a synced node with 8 peers, while balances read fine #433's premise was disproved;
• entries: [] and a fabricated zero are identical on the wire and are told apart by state — that
  distinction is a claim about money, so it is worth writing down;
• chain_unreadable is a catch-all for five structurally different states, only one of which is a
  chain read failing. Two of the five are terminal, so a node in either answers chain_unreadable
  forever while its chain reads work perfectly, sending an operator to inspect peers that are fine.

Why it is not being rebased right now

The version here is 0.179.1 and main is at 0.187.0, so it needs a rebase and a re-bump.
Doing that while PR #442 is in its gate round would put two concurrent PRs in this repo both
computing a next version from the same base — which is precisely how #442 acquired the version
collision this wake had to repair. One at a time.

Resume condition, checkable

When PR #442 has merged: rebase this branch onto the new main, re-bump to that version's next
patch (docs-only), and re-open the gate. After any rebase here, re-read the version from
Cargo.toml on disk and scan the rebase output for dropping — a rebase silently discards a
version-bump commit whose patch is already upstream, and reports success while doing it.

One correction to the PR body

Its measurement was taken against a build of 9eb8fbd (0.179.0), which predates the L1-genesis
mirror-signing fix (bcb96454, merged 06:33Z). So the created=0 in that reading is not evidence
that this node had nothing to create — under the L2 genesis every mirror create was being rejected by
Chia outright. The observation that state: "known" makes entries: [] a truthful published
observation still holds; the reading is sound about the surface and stale about the cause. The real
end-to-end proof landed separately on mainnet (coin 31e90772… created in block 9,224,641, reclaimed
in 9,225,254, 25.000 $DIG returned whole).