Treat monitor-held spontaneous payments as in flight

[Jainakin]

Summary

Treat a spontaneous payment with a partially accepted route as in flight instead of reporting a resend-safe failure.

Root cause

pay_route_internal() returns PaymentSendFailure::PartialFailure when at least one path has entered the channel state machine but cannot be released yet, including APIError::MonitorUpdateInProgress. The existing wrapper converted every error into RetryableSendFailure::RouteNotFound, emitted PaymentFailed, and allowed callers to retry while the original HTLC was still pending.

That behavior can duplicate a payment attempt across a monitor-persistence boundary.

Change

• Return success for PartialFailure, preserving the pending outbound payment.
• Do not emit PaymentFailed for an in-flight partial result.
• Keep true all-path failures on the existing failure path.
• Log success, durable-state wait, and failure as distinct outcomes.
• Add a focused regression test for MonitorUpdateInProgress.

Validation

• cargo check -p lightning --lib --features _rln_test_hooks passes on current dev.
• The focused regression passes as part of the restored 1,188-test suite in Make RGB channel funding restart-safe #32.

Current dev cannot compile its unit-test target independently because the UTEXO fork has pre-existing disabled test utilities/macros. The attempted focused invocation fails in unrelated test modules before this test can run. #32 restores that test harness; this limitation is stated here rather than hidden.

Relationship to #32

#32 already contains this safety fix because it was discovered while exercising delayed monitor persistence. This narrow PR exists so the payment semantic can be reviewed independently. If accepted first, #32 should be rebased to drop the duplicate hunk.