[18.0][FIX] sale_operating_unit: strict journal selection for OU sale orders

[IJOL]

Problem

`sale_operating_unit._compute_journal_id` searches for the invoicing
journal with a domain that mixes `operating_unit_id = <so.ou>` and
`operating_unit_id = False` in a single OR clause, then takes
`limit=1` without an explicit order. When the database happens to
return a no-OU journal first, the sale order's `journal_id` is
silently set to it, and the invoice created from that SO inherits
the wrong journal. Downstream,
`account_operating_unit._check_journal_operating_unit` may trip with:

The OU in the Move and in Journal must be the same.

This can happen in perfectly configured multi-OU companies whenever
legacy no-OU journals coexist with OU-scoped journals.

Fix

Perform two separate searches:

1. First prefer journals whose `operating_unit_id` exactly matches
   the SO's OU.
2. Only fall back to a no-OU journal if no matching one exists.

The no-OU fallback is preserved for deployments that legitimately use
a shared journal across OUs.

Test

Includes a TDD regression test (`test_create_invoice_journal_ou.py`)
that:

• creates two sale journals in the same company, one in OU1 and one
  in B2B (OU1 first, so its id is lower → it would be picked first
  by the previous OR-based domain);
• creates a sale order as a B2B-restricted user;
• invoices it and asserts that `invoice.journal_id.operating_unit_id`
  equals B2B.

Fails on upstream/18.0, passes with this fix.