[ENG-1190] fix(fees): compensate v1 compute_budget-field mass on devnet

[zelenevn]

The wallet undercounts compute mass for v1 (non-native subnetwork / lane) transactions, causing kaspad to reject high-input-count lane payloads as non-standard. This adds the missing per-input mass term, modeled as an explicit per-network compensation policy so the fee math never branches on network identity.

Problem
kaspad's transaction_input_estimated_serialized_size counts a 2-byte compute_budget field per input for version >= 1, but the wallet's serialized-size helper omits it. The wallet therefore undercounts compute mass by 2 * mass_per_tx_byte per v1 input. The shortfall scales with input count and, past a few hundred inputs, drops the estimate below kaspad's non-standard relay-fee floor.

Observed on the devnet L2 loadgen run: the BatchTransfer contract deployment was rejected with

transaction has 9890100 fees which is under the required amount of 9906600 for compute mass 99066

— short by exactly 2 * inputs - payload_len. No load could start.

Solution
The mass kaspad charges is network-independent (a function of ConsensusParams + tx version), so the fix keeps the calculation network-agnostic and expresses the rollout decision as policy:

• Extract a free compute_mass_for_unsigned_consensus_transaction that takes a &MassCompensations policy; the generator method is a thin wrapper. The math never inspects the network.
• MassCompensations::for_network is the single seam mapping network → enabled compensations. The pre-existing v1_script_mass term stays on for all networks; the new v1_compute_budget_field term is enabled on devnet only.
• Both terms apply exclusively to v1 transactions; v0 native payments are untouched on every network.

Adding a future compensation is a new policy field plus one for_network line — not another network conditional inside the calculation.

Backward compatibility

mainnet/testnet/simnet resolve v1_compute_budget_field: false, so their fee sizing is byte-for-byte unchanged. Only devnet sees the new term.

Testing

• MassCompensations::for_network mapping across all four network types.
• Opt-in behavior of the compute_budget-field term: enabling it adds exactly COMPUTE_BUDGET_FIELD_SIZE * mass_per_tx_byte per v1 input, with no effect on v0 transactions.
• cargo test -p kaswallet-daemon --lib — 51 passed; cargo clippy --all-targets and cargo fmt --check clean.

[pycckuu]

Code looks good, just a couple of suggestions.

[pycckuu]

Issue: Replacing the documented workaround with two undocumented flags loses the lifecycle of each compensation. v1_script_mass and v1_compute_budget_field cover independent upstream omissions that can be fixed separately, while the existing upstream canary only detects that the aggregate v0/v1 result changed and cannot identify which flag became stale. With the dependency following upstream master, that ambiguity can turn a future fix into an accidental overcount.

Suggestion: Add field-level documentation naming the exact upstream omission and removal condition for each flag, and split the upstream canary so script-mass support and compute-budget byte accounting are detected independently.

[pycckuu]

Issue: This regression test compares the helper with its flag disabled and enabled, then derives the expected delta from the same COMPUTE_BUDGET_FIELD_SIZE constant used by production. It can pass even if that constant or formula drifts from kaspad, and it does not exercise the network policy, generator wrapper, and final fee-mass path that failed in production.

Suggestion: Add a node-parity regression using a signed, non-native v1 transaction under devnet parameters, preferably with enough inputs to reproduce the original fee-floor case, and assert that the wallet's final noncontextual fee mass matches the canonical consensus mass calculation.