[Bug]: Customer Credit UI counts payment as settled but submit flow does not send redemption payload

[my-dev-jour]

Bug Description

Customer credit is added in the POS UI as a special payment entry, and the dialog counts it toward totalPaid, so the cashier can complete the invoice as if it were fully paid.

However, the invoice submit payload strips the customer-credit metadata and sends only plain payment rows. The backend only performs actual customer-credit redemption when it receives customer_credit_dict together with redeemed_customer_credit.

I could not find the frontend sending those redemption fields in the normal submit flow.

Why This Is Distinct From #192

Issue #192 covers the first failure mode where POSNext tries to resolve a GL account for mode_of_payment = "Customer Credit" and errors before save.

This issue is the deeper frontend/backend contract bug:

• the UI treats customer credit as settled payment
• but the normal submit payload does not send the backend redemption payload
• so even if the account-lookup failure is bypassed, the intended redemption path still is not invoked correctly

Expected Behavior

When customer credit is applied in the payment dialog, the submit request should invoke the backend customer-credit redemption path correctly.

That means either:

• the frontend sends customer_credit_dict and redeemed_customer_credit, or
• the backend translates the special payment entry into that redemption path before submit

Actual Behavior

The frontend counts customer credit as payment, but the normal invoice submission payload only sends plain payments rows.

Steps to Reproduce

1. Enable customer credit payment in POS Settings
2. Give a customer available credit from a return / prior credit source
3. Open a new sale for that customer
4. Apply Customer Credit in the payment dialog
5. Complete the invoice flow
6. Inspect the payload/behavior versus the backend redemption path

Impact

• the cashier can believe the invoice is fully paid when customer credit has not actually been redeemed through the intended backend flow
• invoices can remain unpaid/outstanding despite UI payment completion expectations
• fixing only the account-lookup error in #192 would still leave an incomplete customer-credit payment flow

Suggested Fix

• send customer_credit_dict and redeemed_customer_credit from the frontend when customer credit is applied
• or convert the special customer-credit payment entry into the backend redemption payload before submit
• do not let the UI count customer credit as settled payment unless the backend redemption path is actually engaged

Notes

This issue is about the frontend/backend contract for customer-credit redemption, not just the missing account error already reported in #192.