This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures.

- **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown name, it previously resulted in an empty response, causing the conversation to stall. This change ensures that a proper error message is now returned to the LLM for the invalid tool call. This allows the LLM to process the failure and continue the conversation.

- **Failing on Limits**: The query processing loop in `_request_llm` has limits for both successive API calls and the number of tool calls per request. Previously, these limits would be reached silently.

  - **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached without the LLM providing a final answer, a `ValueError` is now raised. This prevents silent failures and makes it clear to the calling code that the request could not be completed.

  - **Tool Call Limit**: If the number of tool calls in a single response exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now provided with a result stating that the limit was reached. This gives the LLM the opportunity to try the unprocessed tool calls again in a subsequent turn.

- **Ignore Explanatory Text**: The text that LLMs often include alongside a tool call request (the "thinking" text) is now ignored to provide a cleaner and more concise final response to the user.

**Issue**
When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback.

**Steps to Reproduce**
1. Create an individual contact and link it to a company.
2. Create a Purchase Order with the individual as a vendor.
3. Create a Vendor Bill with the same individual as the vendor.
4. Try to perform Bill Matching.
5. A `ValueError: Expected singleton: res.partner(...)` is raised.

Video for reference:
https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view

**Root Cause**
Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error.

**Fix**
Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company.

Opw-5050339
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#226130

Steps to reproduce:
-------------------
1. Enable self orderdering, and set an online payment method
2. Open 3 tabs: the main PoS one, the self order one, and the preparation display one (we have to setup the prep display too)
3. In the self order tab, make an order and pay for it

Observe that in the main tab, a receipt modal (window.print) appears, and the order is not sent to the payment display (on the third tab) until we either dismiss or accept the printing popup on the main tab.

Reason:
-------
If there is no printing device connected, we fallback to printing the receipt with `window.print`; this operation blocks the execution of the code that follows it, in our case sending the order to the preparation display, until we either dismiss or confirm the printing popup.

Now if the user is not paying attention to the main tab (only looking at the preparation display for instance), the order will not appear in the prep display.

Fix:
----
In the case of fallbacking to web printing, we execute the print in a `setTimeout`, so to not block the code that comes after it.

opw-5039685

Forward-Port-Of: odoo/odoo#225742

### Issue: 
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

### Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry" 

### Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`.
The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute`
Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

### Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

opw-5056938

Forward-Port-Of: odoo/odoo#225558

This commit adds a test for the [change made in community](https://github.com/odoo/odoo/pull/225558).

### Issue: 
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

### Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry" 

### Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`.
The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute`
Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

### Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

opw-5056938

Forward-Port-Of: odoo/enterprise#94111

Scenario:

- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
  SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image

Result: an error 500 with this traceback error:

```py
 File "addons/website/models/mixins.py", line 92, in get_website_meta
     opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
     ._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
 File "odoo/tools/urls.py", line 59, in urljoin
     raise ValueError("Extra URL must use same scheme and host as base,
     and begin with base path")
```

Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.

Fix: save a relative URL instead of an absolute one.

opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544

__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.

__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494

Forward-Port-Of: odoo/odoo#228253