pay: Limit splitting when CLTV budget exhausted

[wqxoxo]

When a payment fails due to CLTV budget constraints, the adaptive splitter creates excessive sub-payments before hitting its lower amount limit. Issue #8167 showed partid reaching 5787+.

The fix adds a cltv_budget_exceeded flag and limits split depth to 3 when set.

Depth 3 means:

• Depth 0: root can split → 2 children
• Depth 1: children can split → 4 grandchildren
• Depth 2: grandchildren can split → 8 great-grandchildren
• Depth 3+: blocked from splitting

This gives max 8 leaf payments exploring different amounts, which empirical testing showed is sufficient for getroute to find lower-constraint paths when they exist. The fix converts O(2^n) exponential to O(1) constant.

Depth counts only SPLIT operations, not retries. The retry_pay_mod also creates child payments, but these are retries of the same amount, not splits. Without this distinction, retries would be incorrectly counted as depth, blocking legitimate splits prematurely.

Fixes #8167

[wqxoxo]

@cdecker I followed up on your feedback from #8721.

This approach only triggers when CLTV budget constraints are exceeded. One of the tests covers your capacity-based example.

The depth-3 limit was based on empirical testing with two paths to the destination - one with high capacity but high CLTV, another with low capacity but low CLTV. The router prefers high-capacity paths for large amounts. As splits reduce the amount, it eventually switches to the low-CLTV path:

• 5:1 capacity ratio (500k vs 100k): switches at depth 2
• 50:1 capacity ratio (1M vs 20k): I tested this and it sometimes fails, sometimes passes with depth 3

Depth 3 caps attempts at ~30, but may fail with extreme capacity differences. I chose it as a conservative bound. Would be curious to hear your thoughts on whether a different threshold makes more sense.