[FIX] purchase_ux: complete the pending criterion in purchase matching

[mav-adhoc]

Completes the criterion of the lines offered by the Match purchase lines button, on top of #351 and #353.

1. Over receipt was hidden on bills

The bill criterion is product_qty > qty_invoiced. When the vendor delivers more than ordered, the line ends up ordered = billed but received > billed, so there is a legitimate quantity left to bill and the line disappeared from the matcher (ordered 40, received 41, billed 40 → 1 pending).

Fixed by adding qty_to_invoice > 0 as a second term, the same criterion the native view uses (purchase/models/purchase_bill_line_match.py, _select_po_line()). The first term is still needed: on products controlled on received quantities qty_to_invoice is qty_received - qty_invoiced, so a confirmed purchase order with no receipt yet gives 0 — that is the regression #353 fixed. The in_refund criterion is untouched.

2. The filter ignored force_invoiced_status

Neither this filter nor the native view read force_invoiced_status / invoice_status, so an order manually set as No Bill to Receive / Nothing to Bill kept offering its lines: with ordered 10 and billed 0 the first term is still True, and button_set_invoiced() only zeroes qty_to_invoice. Setting the status is the documented way to close an order for billing, so those lines are now excluded, on bills and on credit notes alike.

Test plan

purchase_ux/tests/test_purchase_matching.py, 7 cases. Bill criterion: confirmed order with no receipt (offered), partial receipt not billed (offered), over receipt 40/41/40 (offered — point 1), fully received and billed (not offered), forced invoice status (not offered — point 2). Credit note criterion: pending refund from a return 600/500/600 (offered), return already credited 600/500/500 (not offered).

Verified locally on 18.0: 0 failed, 0 errors of 10 tests. Reverting only account_move.py fails test_bill_over_receipt and test_bill_forced_invoiced_status, and leaves the other five green.

Known limitation, out of scope

A line returned and already credited (ordered 150, net billed 0) still shows as 150 pending on bills. It happens with the previous criterion and with the native one too; whether it is tolerated is a product decision.

https://www.adhoc.inc/odoo/project.task/72358

3. Orders closed with the Set Invoiced button

button_set_invoiced() stamped invoice_status on the order and zeroed qty_to_invoice on its lines. Both are stored computed fields, so the next recompute undid it: right after pressing the button the order reads Nothing to Bill instead of No Bill to Receive, and any later recompute — writing on a line is enough — brings it back to Waiting Bills with the full quantity pending. Neither the matcher nor the line status ever treated those orders as closed, since both read force_invoiced_status, which the button never set. It now writes that field, which is durable and is what the rest of the module reads. This is the path a mass cleanup goes through, so without it the exclusion of point 2 never applies to it.

test_bill_set_invoiced_button covers it: after the button the order keeps force_invoiced_status and No Bill to Receive, the matcher does not offer its lines, and a later change of the received quantity does not bring it back. The behaviour was verified on 19.0 (same code); on 18.0 it rides on CI. The line level status of those orders only becomes correct together with #361.

[roboadhoc]