CCH default fee configuration is too low and can produce zero fee budgets

Problem

The current CCH fee defaults are extremely low:

#[default(0)]
pub base_fee_sats: u64,

#[default(1)]
pub fee_rate_per_million_sats: u64,

The fee is then calculated with integer division:

fee_sats = amount_sats * fee_rate_per_million_sats / 1_000_000 + base_fee_sats

For send_btc, the equivalent calculation is done from millisatoshis:

fee_sats = amount_msat * fee_rate_per_million_sats / 1_000_000_000 + base_fee_sats

With the current defaults (base_fee_sats = 0, fee_rate_per_million_sats = 1):

• any order below 1_000_000 sats collects 0 sats of fee;
• an order of exactly 1_000_000 sats collects only 1 sat;
• the outgoing payment fee budget is derived from the collected fee_sats, so the default can leave CCH with no realistic routing-fee budget.

This makes the default configuration impractical for real CCH operation and easy to misconfigure silently. It is related to the broader fee-budget failure mode discussed in #1272, but this issue is about the default CCH fee configuration itself.

Expected behavior

The default CCH fee settings should be operationally reasonable, or the node should make it clear that operators must explicitly configure them before enabling CCH.

Possible directions:

• set a non-zero default base_fee_sats so small orders never collect a zero fee;
• set a more realistic default fee_rate_per_million_sats;
• reject or warn on CCH startup when both the base fee and effective proportional fee would produce an unusably small outgoing fee budget;
• document recommended production values in the CCH configuration docs / generated help.

Relevant code

• crates/fiber-lib/src/cch/config.rs: defaults for base_fee_sats and fee_rate_per_million_sats
• crates/fiber-lib/src/cch/actor.rs: CCH order fee calculation for both send_btc and receive_btc
• crates/fiber-lib/src/cch/actions/send_outgoing_payment.rs: outgoing fee budget is derived from collected fee_sats

Impact

Operators who enable CCH without overriding these defaults may accept orders that collect no fee, and outgoing payments may fail or be constrained to unrealistic fee budgets. Even when payments succeed, the operator is not compensated for routing/liquidity costs under the default settings.