[Bug]: Partial payment API is not atomic and can leave Payment Entries after failure

[my-dev-jour]

Bug Description

The partial payment flow commits Payment Entry documents inside helper-level code, while the outer API still behaves as if the overall operation can be rolled back on failure.

If one payment entry is committed and a later step fails, the request can return failure while one or more Payment Entry documents already exist.

Expected Behavior

Partial payment submission should be atomic:

• either all related payment entries are created successfully
• or none are persisted

Actual Behavior

The flow uses internal commits and then relies on outer rollback / compensating cancellation, which is not equivalent to real transactional rollback.

Steps to Reproduce

1. Start a partial payment flow that creates more than one payment-related record
2. Trigger a failure after at least one Payment Entry has been created
3. Inspect the accounting documents after the API returns an error

Impact

• accounting state can remain partially persisted after a failed request
• operators can see failed payment attempts that still created payment documents
• cleanup depends on best-effort cancellation recovery, which can also fail

Suggested Fix

• remove helper-level commits from the partial payment path
• keep transaction control only at the orchestration layer
• if true atomicity is not supported, document the operation as best-effort instead of rollback-safe

Notes

This appears separate from incorrect paid/outstanding amount issues. The core problem here is transaction safety.