fix(engine)!: cap the fee intent's compute at a flat credit

[sdbondi]

Also carries #2439's outstanding review fix

ConsensusConstants::DEVNET is initialized by a call to devnet, and an associated const whose
initializer is a const fn call is not evaluated by a runtime use of it — so devnet's body
escaped the compile-time ceiling check the other three networks get by being const items their
constructors return. Verified: a 20_000 bps rate in devnet's body compiled clean while the same
edit to MAINNET failed with E0080.

Note the fix suggested in review — falling back to Self::DEVNET in From<Network> — does not
work; I applied it and the bad rate still compiled. A const _ item of the type is what forces the
evaluation.

The hole

A payment raised the compute allowance inside the fee intent
(StateTracker::wasm_point_allowance: points_funded_by(unspent) + FREE_COMPUTE_GRACE_POINTS).
But the fee checkpoint — the only thing that makes a fee collectable — is taken in
checkpoint_fee_intent() after the last fee instruction. An abort before that leaves no
checkpoint to fall back to, so the transaction settles as a rejection that collects nothing.

Fee-intent compute was therefore payment-funded but not payment-bound: declaring a larger
max_fee raised the ceiling on work that was never paid for, repeatably, with the same funds.

That made the main intent pointless. The same work costs nothing when it fails in the fee intent
and costs a fee-intent commit when it fails in the main instructions — for an allowance that was no
smaller. There was no reason to use the main intent at all.

The change

The fee intent now runs on a flat FREE_COMPUTE_GRACE_POINTS, whatever it has paid. The credit
is sized to source a fee and that is all it authorizes. Payments raise the allowance only past the
checkpoint, where a failure still commits the fee intent and collects. Work that needs more than the
credit has to go in the main instructions.

Unpaid work per transaction is bounded by a constant again, rather than by the fee the sender
declares.

StateTracker::compute_allowance replaces wasm_point_allowance and reports what authorizes the
allowance (ComputeFunding::{FeeIntentCredit, Payment}) alongside the points, so exceeding it in
the fee intent is reported as the credit being exhausted — paying more will not help, and the
message says to move the work to the main instructions — rather than as underpayment. Two new
error variants carry that: WasmExecutionError::FeeIntentComputeExceeded on the trap path and
RuntimeError::FeeIntentComputeExceeded on the native pre-charge.

The "WASM not priced ⇒ no bound" case is preserved via WasmMeteringRate::prices_execution(), so
fee-disabled tests keep only the per-transaction hard cap.

The credit stays at 32M

It was already sized at ~3x the most expensive legitimate fee-sourcing flow. What changes is that
the headroom is now a ceiling rather than slack, so a real flow sitting closer to it than
grace_covers_legitimate_fee_sourcing_flows and complex_fee_payment cover would now be rejected.
Worth a second opinion on whether anything sits in that gap.

Breaking change

Compute in the fee intent is capped at FREE_COMPUTE_GRACE_POINTS regardless of the fee paid, so a
transaction that ran more than that in its fee instructions is now rejected.

Test plan

• New regression test paying_first_does_not_raise_the_fee_intents_allowance: pays first, then
  runs an above-credit call inside the fee intent. Verified it fails under the old behaviour
  — with the payment-funded fee-intent branch restored it reports "Transaction succeeded but it
  was expected to fail".
• fee_intent_cannot_exceed_grace_compute and the two native_compute_budget fee-intent cases
  now assert the credit message, matched loosely so the constant can move.
• cargo check --workspace --tests
• tari_engine --test {fees, compute_fee_budget, native_compute_budget, metering_budget, complex_fee_payment, limits}
• tari_template_builtin --test liquidity_pool
• Wallet SDK stealth-transfer tests — their merged-statement budget is a share of the credit,
  which is now a hard cap rather than a floor.

[sdbondi]

Verdict

The core change is right and strictly a tightening — compute_allowance in the fee intent can only ever return less than before, so no new attack surface. The diagnosis (fee-intent abort ⇒ no checkpoint ⇒ collects nothing ⇒ payment-funded compute there is free) holds, and the fix is at the right seam. The tests discriminate properly: assert_fee_intent_credit_exceeded matches "compute credit", which neither InsufficientFeesForCompute nor InsufficientFeesForNativeExecution contains.

Findings

1. Dry runs skip the credit, so fee estimation can't surface the new rejection. compute_allowance returns None on is_dry_run() before reaching the fee-intent branch. That guard was justified when the bound depended on a payment the estimator hadn't decided yet — but the fee-intent credit is now flat and payment-independent, so enforcing it during a dry run costs nothing in estimate accuracy and is the only way a wallet learns before submission. As it stands a dry run succeeds and the real transaction comes back with "move this work to the main instructions" and no remediation. Consider returning Some(ComputeAllowance { points: FREE_COMPUTE_GRACE_POINTS, funding: FeeIntentCredit }) even in dry runs, and moving the is_dry_run check into the payment branch.

2. The ? in the payment branch is now dead, and fails open. points_funded_by returns None iff per_point_cost == 0, which !rate.prices_execution() already returned on. If anything later adds a second None case, the ? silently makes the allowance unbounded rather than zero. .unwrap_or(0) (or expect) is the fail-closed form.

3. credit_points is hardcoded in the trap path. wasm/process.rs reports limits::FREE_COMPUTE_GRACE_POINTS rather than allowance.points — equal today only because the fee-intent branch constructs it from that constant. Carrying the value through also removes the expect("BUG: allowance_remaining is Some"):

let allowance_remaining = allowance
    .map(|a| (a, a.points.saturating_sub(consumed.saturating_add(native_consumed))));
let points_before = match allowance_remaining {
    Some((_, remaining)) => per_call_cap.min(budget_remaining).min(remaining),
    None => per_call_cap.min(budget_remaining),
};
let binding = allowance_remaining
    .filter(|(_, r)| *r < budget_remaining && *r <= per_call_cap)
    .map(|(a, _)| a);

4. Stale comments. In wasm/process.rs, above the allowance block: "Cap further to the compute the fees paid so far can cover (plus the free-compute grace)" — no longer true in the fee intent. Same for the "measured against the charges standing when it is asked" paragraph in compute_allowance's doc, which now only describes the payment branch but reads as covering the whole function.

5. The native pre-charge branch has no paying-path test. paying_first_does_not_raise_the_fee_intents_allowance pins the WASM trap; both native tests are non-paying, so nothing pins that a payment doesn't lift the native allowance in the fee intent — the RuntimeError::FeeIntentComputeExceeded arm. A paying variant of unpaid_native_verification_traps_before_the_crypto_runs is cheap.

On "whether anything sits in that gap"

Stealth shapes do. STEALTH_LIMITS permits one fee-intent transfer with up to 16 outputs and 1000 inputs — ~140M points (2.1M + 16×6M + 1000×42k). unpaid_native_verification_traps_before_the_crypto_runs already uses an 8-output statement at ≈50M. Anything from ~5 outputs (2.1M + 5×6M = 32.1M) or ~710 inputs upward is now unconditionally rejected in the fee intent, where previously paying first made it work.

In-tree that's covered: the wallet SDK's merged_statement_fits_credit already sizes merged statements at 80% of the credit, and its doc comment already describes the credit as the entire allowance funding the fee intent until pay_fee settles — i.e. it was written against the new model. So this only bites clients building fee-intent transfers directly. If that's acceptable, worth tightening the fee-intent stealth caps (alongside max_fee_intent_transfers: 1) so those shapes fail at the structural check with a clear message rather than as a compute trap.

Minor

• The const _ doc says "nothing else reaches it at compile time", but the same commit makes From<Network> reference Self::DEVNET via map_or. Given the verification that a runtime reference alone doesn't force evaluation the comment is accurate, but it reads as contradicting the code two lines below — worth a clause. The const _ only pins the default committee size, which is fine since nothing in devnet's body depends on the argument.
• This is a consensus-visible execution rule change with no epoch gate, unlike the seam exhaust_burn_rate(&self, _epoch) sets up. Presumably fine pre-mainnet, but worth being deliberate about.

[sdbondi]

Re-reviewed at 7aa5a68. All five points are addressed, and correctly:

• The dry-run guard moved into the payment branch, which is the right split — the credit is the same figure either way, and past the checkpoint there genuinely is no payment to derive a bound from.
• unwrap_or(0) is the fail-closed form, and the comment above it says why.
• binding_allowance carries the allowance through, so credit_points is now the figure that actually bound the call and the expect is gone.
• paying_first_does_not_raise_the_fee_intents_native_allowance pins the native arm with a payment that funds the statement four times over, and reuses the corrupted proof so it still proves the pre-charge fired first.

Three follow-ups, all on the dry-run change:

1. The dry-run enforcement is itself untested. It's the behavioural change in this commit — a dry run of an above-credit fee intent now aborts where it previously ran unbounded — and nothing asserts it. A dry run of fee_intent_cannot_exceed_grace_compute's transaction, asserting the credit message rather than a required_fees() figure, would pin it. Without that, the guard can drift back to the old placement and every test still passes.

2. charge_native_execution's doc is now stale. It still reads: "No allowance applies (dry runs, unpriced WASM execution) ⇒ the charge only accumulates, so dry-run fee estimates stay accurate." Dry runs are no longer in that set inside the fee intent — the pre-charge can now reject one. The parenthetical wants narrowing to unpriced WASM execution, plus the past-checkpoint dry-run case.

3. fees.mdx "Estimating what to submit" says the engine "meters it exactly as it would for real, but never aborts for insufficient payment." Still literally true — the credit is not an insufficient-payment abort — but it now reads as a promise that a dry run always yields a required_fees(). This is the user-facing payoff of the change and worth a sentence: the fee intent's credit binds a dry run as it binds a real run, so a fee intent above it fails estimation rather than surfacing at submission.

Nit: the reworded comment in process.rs lost its subject — "The allowance when it — not the per-transaction hard cap — is what bounds this call."

On the consensus comment: "a const whose initializer is a const fn call is only evaluated by a const context" is an observed rustc behaviour rather than a documented guarantee, so it's worth reading as the reason the const _ is there rather than as a rule to rely on elsewhere. The const _ holds either way, which is the point.

[sdbondi]

Re-reviewed at f7cbcb9. All three follow-ups landed, and the dry-run test does pin the guard: move it back to the combined is_dry_run() || !prices_execution() early return and the 64M call runs unbounded to success, so execute_expect_failure fails. The const _ comment now separates the observation from the reason the item is there, which is the right split.

Three things in this commit:

1. enable_fees lost its doc comment to set_dry_run. The new method was inserted between the existing doc and the function it documented:

/// Enables fee charging for subsequent transaction executions.
/// By default, fees are disabled in tests.
/// Executes subsequent transactions as a dry run: fees are metered but not settled, as the
/// indexer's fee estimation does.
pub fn set_dry_run(&mut self, dry_run: bool) -> &mut Self { … }

pub fn enable_fees(&mut self) -> &mut Self { … }

set_dry_run now carries all four lines and enable_fees is undocumented.

2. Stray unrelated change. crates/wallet/ootle-rs/examples/stealth_transfer.rs swaps the hardcoded recipient address. Nothing in this PR touches that path — looks like a local scratch edit that got swept into the commit.

3. The new docs paragraph breaks the antecedent below it. It sits between "Read FinalizeResult::required_fees() … and use it as the max_fee" and "That figure is total_fees_required + FEE_ESTIMATE_ALLOWANCE". "That figure" now trails a paragraph ending in "restructure the transaction" rather than the required_fees() sentence it refers to. Moving it below the FEE_ESTIMATE_ALLOWANCE bullets — it is a caveat on estimation as a whole, not on the figure — keeps both readings intact.

Nothing outstanding on the substance. CI: everything green so far, test (1-3/3), clippy and integration still pending.