-32044 collides: WALLET_COINS_RESERVED vs dig-node's shipped WALLET_NODE_SPEND_DISABLED

[MichaelTaylor3d]

-32044 now means two opposite things

dig-node-control-interface 0.20.0 allocates:

-32044  WALLET_COINS_RESERVED             "This is a wait, NOT a shortfall."

dig-node has already shipped -32044 with a different meaning, and it is the DEFAULT refusal on
control.wallet.broadcast:

crates/dig-node-service/src/meta.rs   ErrorCode::WalletNodeSpendDisabled => -32044
crates/dig-node-service/src/control.rs:2426   (emitted)

Its own doc says: "the bundle spends a coin at one of the NODE's OWN custodied puzzle hashes while
DIG_WALLET_ENABLE_LIVE_BROADCAST is off … Retrying cannot help."

So the same integer instructs a client to retry after a wait and that retrying cannot help.
Those demand opposite actions, and one of them is about money moving. This is exactly the
shortfall-vs-wait confusion WALLET_COINS_RESERVED was introduced to prevent, reappearing one layer
down.

Not a reasoned worry — dig-node's own gate fails on it

Implementing the three methods on loop/3127-serve-reservations makes dig-node's pre-existing
uniqueness test fail:

meta::tests::error_codes_are_unique_and_upper_snake
  panicked: duplicate numeric code -32044

403 other tests pass. That one failure is the whole blocker.

Recommended fix — the contract moves, not dig-node

• WALLET_COINS_RESERVED -> -32046, WALLET_RESERVATIONS_UNAVAILABLE -> -32047.
• Register WALLET_NODE_SPEND_DISABLED at -32044 in the shared catalogue, which is the root
  cause: dig-node minted a code inside the shared -3204x wallet range without it ever being
  declared here, so nothing could detect the clash at allocation time.

Rationale: -32044-as-spend-disabled is shipped and reachable today on every default install,
while -32044-as-coins-reserved was published hours ago with zero implementors — dig-node's
branch is the first. Renumbering the unshipped side costs a version bump; renumbering the shipped
side breaks any client already decoding it.

dig-node takes both numbers from this crate's constants rather than restating them, so a
renumber here needs no dig-node code change beyond the dependency bump.

Worth adding either way

A test asserting every catalogued code is unique and that no implementor has minted an
unregistered code in a reserved range. The collision was invisible because the two catalogues were
never compared.

Filed from the dig-node serve lane for https://github.com/DIG-Network/dig_ecosystem/issues/3127.

[MichaelTaylor3d]

Resolved by 0.21.0 and adopted in DIG-Network/dig-node#344 — a dep bump and a recompile, no logic change, because both codes take their numbers from this crate's constants.

The reciprocal half now lives in dig-node (every_wallet_band_code_dig_node_mints_is_declared_in_the_shared_catalogue): every -3204x code dig-node mints must appear in ControlErrorCode::ALL, matched on number and symbol. Mutation-tested 3/3 against an undeclared in-band code, a name disagreement between the two catalogues, and a production code() arm drifting off this crate.

One thing worth recording here for the next band change: dig-node mints ~20 codes in the shared -320xx space that this crate never declares (-32001..-32017, -32033, -32050..-32052, -32060). None clashes today and all sit outside -3204x, so nothing is broken — but if a future allocation extends past -3204x, that is the set it would collide with.

[MichaelTaylor3d]

This collision is already resolved — this ticket can close.

Verified on origin/main of both repos while declaring -32048 for
#31:

• feat(wallet)!: move the reservation codes off -32044, which dig-node already owns #28 (eca2d91, v0.21.0) moved the reservation codes off -32044/-32045 onto -32046/-32047,
  so dig-node's already-shipped WALLET_NODE_SPEND_DISABLED keeps -32044 uncontested.
  src/error.rs now declares -32046 WALLET_COINS_RESERVED and -32047 WALLET_RESERVATIONS_UNAVAILABLE.
• dig-node carries a standing guard against a recurrence:
  crates/dig-node-service/src/meta.rs:1217
every_wallet_band_code_dig_node_mints_is_declared_in_the_shared_catalogue cross-checks every
  -3204x code dig-node mints against ControlErrorCode::ALL by number and symbol, and refuses
  to pass vacuously (it asserts at least 3 codes are in band). meta.rs:1279 pins the three
  dispositions.

Left -32045 vacant rather than reusing it: re-using a number a shipped build once carried is how
-32044 became ambiguous in the first place.