### Steps to reproduce the issue:
1. Download Sales, accounting and l10n_mx
2. Go to settings and be sure that in electonic invoicing the PAC is set on Quadrum and the Testing box is activated (no username and no password needed)
4. Create a SO quotation with a product and confirm it
5. Create a downpayment invoice for that quotation and be sure that the Payment way is selected
6. Send to CFDI
7. Click Request Cancel button and select reason 01
8. Then click create replacement invoice, confirm the new one and send it to CFDI
9. Go back to the first invoice created and click request cancel (you will have only 1 choice in the dropdown menu) and confirm it
10. See that in the CFDI page the request is sent
11. Wait 7 min and and then in the CFDI page click "retry" in the line of Cancel in Error state
12. Invoice is cancelled

### Issue before this commit:
In the SO we can now see that the down payment invoice amount is still considering both the invoices even if the first one has been canceled. After the original downpayment invoice is successfully cancelled on the SAT side, the Sales Order continues to consider both the original and the replacement downpayment invoices. This results in the Downpayment line on the Sales Order showing a price_unit that is the sum of the two downpayments.

### Cause of the issue:
The _compute_price_unit method on the sale.order.line model does not take the Mexican CFDI state (l10n_mx_edi_cfdi_state) into consideration. It only checks if the associated invoices are in a posted state. During the SAT cancellation flow for downpayments, the accounting move often remains in a posted state because of its reconciled payment (the system silently passes the UserError triggered during the accounting cancellation). Since both the cancelled original invoice and the replacement invoice remain posted at the accounting level, the _compute_price_unit logic sums both of them.
https://github.com/odoo/odoo/blob/cbabc49d8004b32be12d834dd370672815087a2b/addons/sale/models/sale_order_line.py#L561-L562

### Reason to introduce the fix:
To ensure that Sales Orders accurately reflect the legal and financial reality for Mexican operations without requiring manual adjustments by the user.

opw-6334903