fix: prevent the release paths from dropping coins the fullnode cannot resolve

[qrayven]

The problem

Three separate places take a set of coin ids, ask the fullnode to resolve them, and release whatever
comes back:

get_latest_gas_objects(ids).into_values().flatten().collect()

flatten() discards every coin the node could not resolve, with no retry. A discarded coin is
never released, and it has already been removed from the registry, so nothing can surface it again:
absent from the free list, absent from every reservation, invisible to expire_coins, and below the
200 × target_init_balance floor the periodic rescan selects on. It is still owned by the sponsor
on chain and permanently unusable by the station.

Where	What a NOT_FOUND means there
the expiry sweep	a read failure, always — the coins were never executed
the failed-execution release	ambiguous — smashed by a transaction that landed anyway, or lost
the rescan re-read	a read failure on a coin the node listed as owned moments earlier

Why the expiry sweep is the worst of the three

It is the one that looks least alarming and is in fact the most dangerous:

• Its None is unambiguous. An expired reservation was never executed, so its coins were never
  consumed and are guaranteed still live on chain. There is no innocent reading — dropping one is
  always a loss.
• It is the highest-volume path. Every reserve-without-execute lands here; a 1000-transaction run
  produces around 110 expiry releases.
• It reported success while losing coins. The released count was computed after the drop, so
  Released N coins after expiration always agreed with itself. Ten in, zero out logged cheerfully
  at INFO. And nothing anywhere incremented num_expired_gas_coins, so the one metric an operator
  would reach for was always zero.

The failed-execution release added its own misdirection: the smashed-coin count was derived from how
many coins came back, so every dropped coin was reported as one the validators legitimately consumed.
The only signal pointing at the problem argued against it.

The fix

All three sites now share IotaClient::resolve_gas_coins, which retries on the existing budget and
returns the ids that never resolved instead of dropping them. Callers decide what that means,
and they decide differently on purpose:

• expiry sweep — warn! plus a new num_unreleased_gas_coins counter.
• failed-execution release — warn! only, and deliberately no counter. That branch cannot tell a
  coin smashed by a landed transaction from a lost one, and counting them would fire an alert whose
  documented remedy is a registry-wiping rescan, for coins that may not exist. The ambiguity is
  stated in the log instead.
• rescan re-read — a loud error!; run_once has no handle to the metrics registry.

Three corrections ship alongside:

• num_expired_gas_coins is incremented at all, and the expiry log reports released of expired
  rather than a number computed after the drop.
• smashed_coin_count is derived rather than guessed. The retry makes it derivable on the failure
  path too: a transaction that never landed resolves every coin and yields 0; one that landed
  resolves the survivor once the lag clears and not the deleted ones, giving the true count.
• num_unreleased_gas_coins is exported at zero from startup, so an absent series never reads as
  "nothing was lost".

The second commit

f258d40 corrects two reporting defects that an adversarial review of the first commit found.
Neither affects custody — no coin is lost or double-released either way — but both made the station
report something untrue.

The expiry site raised invariant_violation, justified by a comment claiming its ids "come from
the station's own registry, never from a caller". Registry provenance is not registry integrity.
Until the payment is bound to the reservation, a caller can have a coin held by reservation A
destroyed by paying with it under reservation B; A then references a coin the validators deleted, and
when A expires that id can never resolve. One reserve/execute pair poisons a future expiry batch, and
the sweep runs every second. Downgraded to a warning, with the prerequisite recorded — it can be
raised once fix/bind-reservation-to-gas-coins lands.

The failed-execution path counted smashed coins as lost while zeroing the smash count, so both
metrics were wrong in the same scenario. It now claims neither.

What this does not do

A coin that stays unreadable past the retry budget is reported, not recovered. It is still not
released. That is the honest limit of this change: it converts a silent leak into a loud one and
bounds the window, but recovering such a coin needs the durable pending-recovery queue described as
Option D in SOLUTIONS.md, which is deliberately deferred until there is data on how
often the budget is actually exhausted.

Deliberately not an automatic rescan trigger. A full rescan wipes the registry and holds a
12-hour maintenance lock during which all reservations are refused — a disproportionate remedy for
one coin, and one whose firing rate a caller can influence.

Verification

Verification	Result
Station test suite (cargo nextest run -j 1)	175/175, including 3 new tests
Each commit builds independently	yes
End-to-end reserve / execute / expire run against a local network	15 of 15 checks pass
Sustained load: 1000 transactions at concurrency 25	25 of 25 checks pass, including 29 executions through the failure release path
Smashed-coin count	matches an independently computed expectation exactly (36 of 36)

Two things worth knowing about what the numbers do not cover:

• The dangerous case is not reproduced. Every deliberately-failing payload is refused before
  execution, so the coins' versions never move and the read cannot lag. The 29 failure-path releases
  prove the branch returns every coin when the read succeeds — nothing more. Forcing a
  dispatched-then-errored transaction needs fault injection at the node boundary.
• The retry now runs where it did not before, including on the rescan, which in RunMode::Init
  lists every owned coin. It sleeps only when something is unresolved, so the common path pays
  nothing, but a startup immediately after a large split can spend up to the full budget.