#33741 rpc: Optionally print feerates in sat/vb

• Allow RPC consumers to optionally receive feerates formatted in sat/vB instead of BTC/kvB
• Eliminate manual unit conversions and potential calculation errors in modern tooling

This pull request adds an optional `sat_vb` boolean parameter to `getmempoolinfo`, `getnetworkinfo`, `estimatesmartfee`, and `estimaterawfee` RPCs. When enabled, feerate figures are returned formatted in sat/vB instead of BTC/kvB. It also introduces a `ValueFromFeeRate` helper in `core_io` to format feerates with fixed decimal precision without using floating-point types.

Problem: Bitcoin Core RPCs historically express feerates in BTC/kvB, whereas modern tooling and users standardly expect sat/vB. Forcing external consumers to perform unit conversions is inconvenient and introduces potential calculation errors, especially with sub-1 sat/vB rates.

P3 · user request

• P3 because it offers a long-requested usability convenience for RPC consumers working in sat/vB
• It is an opt-in parameter on existing RPCs rather than a bug fix or architectural prerequisite

It delivers a long-requested usability improvement for RPC consumers who work in sat/vB. Because it is an opt-in parameter on existing RPCs rather than a bug fix or architectural requirement, it is useful but deferrable.

Membership: Adds RPC arguments and modifies JSON output formatting across several RPC commands.

Factors: security/stability 0, bug 0, performance 0, user value 2, leverage 0

• Ready to review; the branch is clean, CI passes, and prior reviewer feedback has been addressed

The branch is clean, CI passes, and all reviewer feedback has been addressed in recent force-pushes.

Author status: active

Resolved concerns:

• maflcko pointed out that floating point arithmetic must not be used for currency representation, resolved by formatting fixed-point strings in ValueFromFeeRate.
• w0xlt noted that estimaterawfee was leaving bucket ranges in sat/kvB while converting the top-level feerate, resolved by updating bucket ranges consistently.
• jonatack recommended snake_case sat_vb per naming conventions, which the author adopted.

• Broad support for standardizing feerate outputs to modern sat/vB conventions (w0xlt, musaHaruna, jonatack)
• Discussed returning distinct fields instead of an argument to avoid configuration hazards (glozow)
• Concerns about floating-point math, bucket ranges, and parameter naming were resolved (maflcko, w0xlt, jonatack)

Positive; multiple Concept ACKs with design discussion from glozow left unanswered.

Reviewers agree on the utility of standardizing feerate units in sat/vB. glozow suggested returning distinct fields rather than adding an RPC parameter to avoid configuration hazards, but the author clarified defaults will not change and glozow did not pursue the objection.

• w0xlt provided Concept ACK and detailed review comments.
• musaHaruna Concept ACKed backwards-compatible migration to sat/vB.
• jonatack Concept ACKed and gave naming guidance.
• glozow discussed whether distinct field keys would be safer than an argument, but did not object to moving forward.

Review verdicts (DrahtBot): 0 (+1)

• Stale ACK: w0xlt
• Concept ACK: musaHaruna, jonatack

100 lines under test/bench/ci.

• test/functional/feature_fee_estimation.py +23/-21
• src/test/rpc_tests.cpp +36/-0
• src/rpc/fees.cpp +25/-10
• src/core_io.cpp +26/-0
• src/rpc/mempool.cpp +12/-10
• test/functional/rpc_estimatefee.py +10/-10
• src/rpc/net.cpp +8/-3
• src/core_io.h +10/-0
• src/rpc/client.cpp +5/-1
• src/rpc/mempool.h +3/-1

This PR adds an optional sat_vb flag to several RPCs (getmempoolinfo, getnetworkinfo, estimatesmartfee, estimaterawfee) to output feerates in sat/vB rather than BTC/kvB. This addresses user frustration and conversion mistakes caused by Bitcoin Core returning legacy BTC/kvB units. The approach is opt-in, non-breaking, and formats numbers using fixed-point math. Concept support is positive across several contributors with no open blocking objections.