### Problem
`pos.config.get_limited_products_loading` orders candidate products by `is_favorite`, service type, last `stock.move.line` date and `write_date`, with no final tiebreaker:

    ORDER BY product_product__product_tmpl_id.is_favorite DESC,
             CASE WHEN product_product__product_tmpl_id.type = 'service' THEN 1 ELSE 0 END DESC,
             pm.date DESC NULLS LAST,
             product_product.write_date DESC
    LIMIT %s

When several candidate products tie on all of those keys — e.g. non-favorite consumable products with no stock moves, created within the same transaction and therefore sharing an identical `write_date` (`transaction_timestamp()`) — the `LIMIT` result is decided by PostgreSQL's unspecified physical scan order. The set of products loaded into the POS session is therefore non-deterministic: which products load can change between runs depending on physical row layout, even though the data is identical.

This is observable as intermittent failures of tests that assert on the limited-loaded product set (e.g. `pos_loyalty`'s `test_product_loading`), passing or failing on scan order rather than on any real data difference.

### Fix
Add `product_product.id` as a final ascending tiebreaker so limited product loading is stable and reproducible. Among products of otherwise-equal loading priority, the lower-id (established) products load first.

### Test
Adds a `TransactionCase` (`point_of_sale/tests/test_pos_product_loading.py`) that creates several products tying on every ORDER BY key and asserts the lowest-id ones load deterministically once the limit is reached.

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#276211