fix(minter-guard): take the deny fee from the chain, not from the library default

[TaprootFreak]

What this fixes

Measured against production after #52 shipped: GET /guard reports gasEnough: false and the dashboard shows
Low gas for a signer that actually holds enough for dozens of denies. With a real proposal pending, the
guard would have refused to act and paged hourly instead.

Cause

The pinned ethers version never asks the chain for a priority fee. In getFeeData()
(lib.commonjs/providers/abstract-provider.js, 6.7.1) it hardcodes one gwei whenever the latest block carries
a base fee:

maxPriorityFeePerGas = BigInt("1000000000");
maxFeePerGas = (block.baseFeePerGas * BN_2) + maxPriorityFeePerGas;

Measured on the live chain: base fee 1,000,000 wei (0.001 gwei), eth_maxPriorityFeePerGas 100 wei,
eth_gasPrice 1,000,100 wei. So the library produces ~1.002 gwei — about 1000× what the chain asks — and
the guard used that both to price a deny and to let the library compose the transaction.

Worth being precise about what was and was not broken: the affordability check was right. EIP-1559 makes
the sender reserve gasLimit × maxFeePerGas, so a transaction carrying an inflated maxFeePerGas genuinely
cannot be submitted by an account that cannot cover the reservation — refusing to send was correct. The defect
is composing the transaction with a fee nobody asked for.

with a 208,000-gas ceiling	reservation	gasEnough	denies affordable
before — library default (1.002 gwei)	0.000208416 cBTC	false	0
after — chain's own fee (0.002 gwei)	0.000000416 cBTC	true	22

Signer balance at the time of measuring: 0.000009335514187595 cBTC.

The change

One new resolveDenyFee() reads the fee from the chain once and returns both the number used for the
arithmetic and the overrides attached to the transaction, so the fee verified as affordable is by construction
the fee that gets sent — the pre-check and the send can no longer disagree.

• EIP-1559 chain: base fee × 2 + the chain's suggested tip from eth_maxPriorityFeePerGas.
• That RPC unsupported or unusable: falls back to the library's tip, then to zero — logging at each step,
  because a zero tip can leave a deny unmined.
• No base fee (non-1559 chain): the legacy gas price, for both pricing and sending.
• Nothing usable: still throws, as before.

Gas amounts and denyGasCeiling are untouched; this is only about the price per gas. The read-only status
path uses the same helper, so estimatedDenyCost and gasEnough now describe the fee the guard would really
pay.

Verification

tsc clean · jest 39/39 in 2 suites · prettier and eslint clean on the touched file · backend image
builds. The table above was computed from values read off the live chain at the time of writing, not from
fixtures.

[TaprootFreak]

Three review passes on this branch, two rounds of fixes, both against the head of the moment.

Round one flagged that the fee was resolved once per cycle and reused for sends spread across minutes; it is
now built per send from the block that send is priced against — the block the window check already fetched, so
no extra call. Round two then found that the affordability check had stayed behind in the pre-check, priced
from a different block two chain calls earlier, so even the first send could still be rejected for funds after
a green pre-check. That check now runs against the exact fee each send carries, using the balance the pre-check
already read.

What remains is stated in the code rather than papered over: the base fee can still move between that final
read and inclusion. The doubling cap absorbs the ordinary case, and beyond it the transaction is simply not
mined at that cap and is retried next cycle — which is not a funds rejection.

One suggestion was deliberately not taken. Multiplying the affordability floor by the candidate count would
have made a signer that cannot afford three denies also skip the one it can afford, and with a veto window
running out, one deny beats none. The trade-off is written down where the choice is made.