fix(pool_sv2): validate extended channel opens before minting an extranonce prefix

[defenwycke]

Closes #744.

The bug, re-verified

Confirmed against main before touching anything, and the numbers were measured rather than assumed:

• bins/pool-sv2/src/lib/channel_manager/mining_message_handler.rs minted the extranonce prefix (next_prefix_extended) and only then ran PayoutMode::try_from(user_identity). On rejection it returned OpenMiningChannelError and the prefix was gone for good.
• ChannelManager::new builds the extended allocator with range_1 = 0..POOL_ALLOCATION_BYTES (4 bytes) and a static prefix of server_id.to_be_bytes() — server_id is a u16, so two of the four bytes are fixed and the counter is 16 bits. The new test extended_prefix_space_is_only_sixteen_bits drains a real factory and asserts the count: 65,535 prefixes for the life of the process.
• Nothing ever hands a prefix back, and is_client_authorized returns Ok(true) unconditionally, so the loop needs no credentials.

One correction to the issue's reading of the allocator: next_prefix_extended checks required_len before it increments, so min-extranonce-size-too-large was never the leaking branch. Every leak came from a check performed after the call.

The fix

Both call orders now live in one place, validate_and_allocate_extended, which the extended path calls: identity first, then the client-controlled hashrate/target checks, then — last — the allocation. This is the order the standard path has always used (PayoutMode::try_from at the top, next_prefix_standard after it).

Reordering rather than reclaiming, as the issue asks: a reclaim leaves a window and has to be right on every error branch, whereas nothing is allocated to reclaim if the request never gets that far.

One extension beyond the issue, called out deliberately

Reordering the identity check alone would have left the same denial of service reachable through a different field. ExtendedChannel::new_for_pool rejects a channel on nominal_hash_rate (any negative value — hash_rate_to_target returns NegativeInput) and on max_target, and both of those run after the prefix is minted, for exactly the same cost to the attacker. A fix that closed only the identity path would have been cosmetic, so those two checks are hoisted ahead of the allocation as well. They duplicate the constructor's first two checks on purpose — the constructor cannot run before the prefix exists, because it takes the prefix — and the constructor keeps its own branches as a backstop.

The constructor's remaining rejections (ExtranoncePrefixTooLarge, ScriptSigSizeTooLarge) are determined by the pool's own configuration and constants, not by anything the client sends, so they are not an attacker lever.

Error code

Every allocator failure previously collapsed into min-extranonce-size-too-large, which blames the client's requested size and points an investigation away from the real cause. Exhaustion now returns extranonce-space-exhausted.

On the spec: OpenMiningChannel.Error.error_code is a free-form human-readable Str0255, and the mining spec enumerates only unknown-user and max-target-out-of-range as examples. Roles are expected to extend that set, and this pool already sends invalid-user-identity, invalid-nominal-hashrate, min-extranonce-size-too-large and standard-channels-not-supported-for-custom-work. The new code follows the same kebab-case convention and fits Str0255.

Tests, and the mutations that prove they can fail

Five tests in extranonce_allocation_tests, all built on a factory with the exact geometry ChannelManager::new uses:

test	what it pins
extended_prefix_space_is_only_sixteen_bits	measures the space (65,535) instead of asserting a guess
rejected_identities_never_consume_a_prefix	66,536 invalid opens — more than the whole space — then a valid open still succeeds
rejected_hashrate_and_target_never_consume_a_prefix	the same property for the other two client-controlled fields
exhaustion_and_oversized_request_report_different_codes	the two faults no longer share a code
the_extended_allocator_has_exactly_one_call_site	the handler cannot mint outside the validating helper

Every test was mutated and confirmed to fail:

mutation	result
allocate before the identity check (i.e. restore #744)	rejected_identities_never_consume_a_prefix FAILED, rejected_hashrate_and_target_never_consume_a_prefix FAILED
MaxValueReached mapped back to min-extranonce-size-too-large	exhaustion_and_oversized_request_report_different_codes FAILED, extended_prefix_space_is_only_sixteen_bits FAILED
allocate before the hashrate/target checks	rejected_hashrate_and_target_never_consume_a_prefix FAILED
a second next_prefix_extended call added to the handler	the_extended_allocator_has_exactly_one_call_site FAILED

The last one exists because the four runtime tests exercise the helper, not the handler, and re-inlining an allocation ahead of the validation is precisely how the bug was written the first time. Building a ChannelManager in a unit test needs a live downstream connection, a template and a prev-hash, so the call site is asserted against the source instead.

cargo test -p pool_sv2 --lib: 29 passed, 0 failed. cargo clippy -p pool_sv2 --tests -- -D warnings and RUSTDOCFLAGS="-D warnings" cargo doc -p pool_sv2 --no-deps both clean.

Known residual, not fixed here

If a client opens an extended channel before the pool has received its first template, the prefix is still minted before the last_future_template / last_new_prev_hash guards reject it. That path disconnects the client and only exists in a pre-template startup window, so it is not an attacker lever, but the standard path checks both at the top and the extended path could be brought into line separately.