[FIX] purchase_stock_ux: keep the forced invoice status on PO lines

[mav-adhoc]

purchase_stock_ux._compute_invoice_status() calls super() — which honours order_id.force_invoiced_status — and then recomputes every line without that guard, overwriting the result:

super()._compute_invoice_status()
for line in self:
    if not float_is_zero(line.qty_to_invoice, precision_digits=precision):
        line.invoice_status = "to invoice"   # <-- overwrites the forced status
    elif float_compare(line.qty_invoiced, (line.product_qty - line.qty_returned), ...) >= 0:
        line.invoice_status = "invoiced"
    else:
        line.invoice_status = "no"

So on an order manually set as fully invoiced, a line with something left to invoice ends up as to invoice and a line with nothing received as no. The order itself keeps the forced status, only its lines lose it, and recomputing the field does not help because the compute overwrites the value again — there is no data fix, it needs the guard.

Setting the invoice status by hand is the documented way to close an order for billing, so the feature of purchase_ux is unreliable at line level on any database with this module installed: the lines keep showing as pending wherever they are filtered by invoice_status. On one customer database this accounts for 2,756 lines that read to invoice on orders that were forced months ago. The code is the same on 16.0, 18.0 and 19.0, so this is not a recent regression.

Test plan

test_forced_invoiced_status_on_lines in purchase_stock_ux/tests/test_purchase_order.py: a confirmed order forced as invoiced keeps invoiced on its lines. Verified locally on 19.0: 0 failed, 0 errors of 8 tests; without the fix it fails with 'no' != 'invoiced'.

Same task as #360, different module and defect. Port of #361 to 19.0.

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

[roboadhoc]

[les-adhoc]

@roboadhoc r+ nobump

[les-adhoc]

@roboadhoc r+