This commit introduces comprehensive logging for AI agent API interactions,
providing visibility into token usage, API calls, and tool execution patterns.

The logging system tracks:
- API calls with estimated token counts (input/output)
- Tool execution (sequential vs batch)
- Timing information for API calls and tool execution
- Summary statistics including total estimated tokens, API calls, tools, and batches

Append `--log-handler odoo.addons.ai:DEBUG` when starting the server to see the
detailed logs.

Example output:
```
DEBUG [AI Prompt] <context>
  <session-info>
    <user id="2" name="Mitchell Admin" model="res.users"/>
    <partner id="3" name="Mitchell Admin" model="res.partner"/>
    <company id="1" name="My US Company" model="res.company"/>
  </session-info>
</context>

<query>
pos orders from restaurant configs containing products from the food categ
</query>
DEBUG [AI Response] Starting generation for model 'gemini-2.5-flash'
DEBUG [AI API Call #1] Sending request with 44360 tokens
DEBUG [AI API Call #1 - →] Received single tool call (3.99s, 16 tokens)
DEBUG [AI Tool →] 'AI: Get Menu Details' with args (menu_ids=[613])
DEBUG [AI Tool - 0.02s] Completed 'AI: Get Menu Details'
DEBUG [AI API Call #2] Sending request with 45432 tokens
DEBUG [AI API Call #2 - ⚡] Received Batch #1, 4 tool calls (2.90s, 77 tokens)
DEBUG [AI Tool - Batch #1 ⚡] 'AI: Get Fields' with args (model_name='pos.order')
DEBUG [AI Tool - Batch #1 - 0.02s] Completed 'AI: Get Fields'
DEBUG [AI Tool - Batch #1 ⚡] 'AI: Get Fields' with args (model_name='pos.order.line')
DEBUG [AI Tool - Batch #1 - 0.01s] Completed 'AI: Get Fields'
DEBUG [AI Tool - Batch #1 ⚡] 'AI: Get Fields' with args (model_name='product.product')
DEBUG [AI Tool - Batch #1 - 0.06s] Completed 'AI: Get Fields'
DEBUG [AI Tool - Batch #1 ⚡] 'AI: Get Fields' with args (model_name='pos.category')
DEBUG [AI Tool - Batch #1 - 0.01s] Completed 'AI: Get Fields'
DEBUG [AI Tool Summary] Batch #1 completed, 4 tool calls
DEBUG [AI API Call #3] Sending request with 50602 tokens
DEBUG [AI API Call #3 - →] Received single tool call (2.98s, 86 tokens)
DEBUG [AI Tool →] 'AI: Open Menu List' with args (menu_id=613, model_name='pos.order', selected_filters=[], selected_groupbys=[], search=['config_id=restaurant'], custom_domain='[["lines.product_id.po
DEBUG [AI Tool - 0.02s] Completed 'AI: Open Menu List'
DEBUG [AI Summary] Total: 10.01s | API calls: 3 (9.87s) | Tools: 6 (0.13s) | Tokens: 140573 (in: 140394, out: 179) | Batches: 1
```

Before:
- If any signer used the eMSigner authentication method, the "Sign Now" option
  was disabled.
- eMSigner does not support signing multiple documents in a bundle, so a warning
  was shown when users tried to add more documents.
- After merging `sign_emsigner`, a traceback occurred when signing with the
 'sms' method because `_validate_auth_method` was called with an unexpected
 `frame` parameter.

After:
- The "Sign Now" option is now allowed when eMSigner is used only by the last
  signer.
- It remains blocked if eMSigner is used by any signer other than the last one.
- Instead of showing a warning, the "Add Document" button is now hidden when
  eMSigner is selected.
- Add `*(kwargs` while calling `_validate_auth_method` auth method when auth
  method is 'sms' which prevent the issue of parameter.

Impact:
- Users can complete signing even when the last signer uses eMSigner, improving
  workflow efficiency.
- The interface is cleaner and prevents confusion by hiding options that are not
  supported.
- The fix for the 'sms' method prevents errors and ensures smoother signing for
  all supported authentication methods.
- Overall, this change improves usability, reduces errors, and provides a better
  user experience.

task-4815486

There are 3 improvements here:
- Attaching PDF and other documents in closing entry moves (like previously)
- Showing the Accounting date by default on draft entries check
- Preventing the Opening Date field to be red when creating a Accounting Periods wizard

In version 18.2, when a closing entry move was generated, the PDF (and other files such as XML) would be send in the chatter. In version 18.3, the Tax returns were changed to have the attachment generated when marking the Tax return as submitted and would be available on the Tax return line. You would still be able to see the closing entry move by using the thre dots next to the Tax return line and selection "View entry" but the attachment wouldn't be included in the chatter anymore. Now, the same attachments from the Tax report line are included in the closing entry move and we made sure to not generate invoices lines from those attachments as they have been generated from the lines we had.

The second improvements was to display the Accounting Date on the Draft entries that needs to be reviewed in a Tax return line to give the user more context on why they need to review those specific Draft entries.

Lastly, when accessing Tax Returns it would ask for us to set the Accouting Periods through a wizard which prefilled informations such as the VAT Periodicity but the Opening Date needs to be filled by this user but this field would show as red when opening the wizard as it is required and no information was prevent. To allow the field to be red only if we try to submit the informations we are passing the informations to the wizard as default value which wouldn't trigger the wizard to try to save values when being created.

task-4784283

This PR introduces several enhancements aimed at improving the default template of the audit reports:

- Headings have been added to articles to establish a clearer content hierarchy and to automatically populate the table of contents.
- The "General Ledger" article has been removed, as it is rarely used in practice and typically not relevant to most audit reports.
- Some sections are now folded by default to avoid displaying contradictory content (for the attestations).
- Labels for foldable sections are no longer shown in the generated resulting in a cleaner and more professional appearance.
- The configuration of the "Balance Sheet" and "Profit and Loss" reports has been updated to provide more meaningful and contextual insights.
- The index of the root article now lists all articles in the report hierarchy.

Additionally, the root article of the audit report will now be named after the audit report itself. This change makes it easier for users to locate the article within the workspace.

Lastly, the "Audit Reports" menu item has been moved under the "Working Files" section of the "Audit" menu to better reflect its purpose and improve navigation.

Task-4999770

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

opw-4850293

Forward-Port-Of: odoo/enterprise#91761
Forward-Port-Of: odoo/enterprise#91570

After this commit https://github.com/odoo/enterprise/commit/40d3314d1b06c8110b476690d2264e86b3492b3e we are not able to cancel a sign request,
if user do not have read/write access on `hr.contract.salary.offer` model

**step to reproduce:**
- install `hr_contract_salary`
- create a new user with following right:
  `Sign        -> Administrator`
  `Contracts   -> Employee Manager`
 `Recruitment -> Interviewer`
- login with test user
- open sign -> All Documents (with demo data 2, there should be 2 documents)
- try to cancel one of them

<img width="1572" height="689" alt="config for user" src="https://github.com/user-attachments/assets/72e89ac7-fed3-4a38-918f-5dbb198bd1e3" />



**Observation:**
- even with Admin rights of Sign, we are not able to cancel a sign request
and we receive a Access Error
`You are not allowed to access 'Salary Package Offer' (hr.contract.salary.offer)
records`

**Fix:**
we use `sudo()` to allow everyone to cancel their sign request


opw-4859774

Forward-Port-Of: odoo/enterprise#91688
Forward-Port-Of: odoo/enterprise#89865

The aim of this commit is to prevent a sick day or any other type of time off taken on a public holiday to be deferred.

To reproduce:
- Create a public Holiday for previous month
- Regenerate the work entries for that month
- Compute a batch of payslip for last month, validate and mark it as paid --> The public holiday should be on the payslip
- OPTIONAL: run the cron `Payroll: Generate pdfs` to make create the payslip in document and make it available to the concerned employee.
- With the concerned employee, put a time off on the whole week of the last month. It should overlap with the public holiday.
- Validate the time off and defer it for next payslip
- Compute a batch of payslip for following month, validate and mark it as paid

Before this commit:
The overlapping sick day gets deferred completely ignoring the fact it was a public holiday.

After this commit:
The overlapping sick day doesn't get deferred.

opw-4903546

Forward-Port-Of: odoo/enterprise#91872
Forward-Port-Of: odoo/enterprise#89264

Currently a below occurs or content is not receiving to odoo WhatsApp when the user uploads a large file (tried with > 35 MB).

Stack Trace:
```
MemoryError: null
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/models/whatsapp_account.py", line 206, in _process_messages
    datas = wa_api._get_whatsapp_document(messages[message_type]['id'])
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 236, in _get_whatsapp_document
    file_response = self.__api_requests("GET", file_url, auth_type="bearer", endpoint_include=True)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 46, in __api_requests
    if 'error' in res.json():
  File "requests/models.py", line 971, in json
    return complexjson.loads(self.text, **kwargs)
  File "requests/models.py", line 928, in text
    encoding = self.apparent_encoding
  File "requests/models.py", line 793, in apparent_encoding
    return chardet.detect(self.content)["encoding"]
  File "__init__.py", line 49, in detect
    detector.feed(byte_str)
  File "chardet/universaldetector.py", line 274, in feed
    if prober.feed(byte_str) == ProbingState.FOUND_IT:
  File "chardet/charsetgroupprober.py", line 70, in feed
    state = prober.feed(byte_str)
  File "chardet/hebrewprober.py", line 240, in feed
    byte_str = self.filter_high_byte_only(byte_str)
  File "chardet/charsetprober.py", line 73, in filter_high_byte_only
    buf = re.sub(b"([\x00-\x7F])+", b" ", buf)
  File "__init__.py", line 186, in sub
    return _compile(pattern, flags).sub(repl, string, count)
```

At line [1], the code `'error' in res.json()` is used, which reads all the json content of `res`, but at times users upload large files, it will cause the above error because the `json()` tries to read all bytes from res, which is a very large amount to handle in memory.

This commit will fix the above issue by returning a response if the response
contains content_length more than 10 MB.

[1] - https://github.com/odoo/enterprise/blob/aca7ae2a7cf4aad5427a60d5cad60d08774357d0/whatsapp/tools/whatsapp_api.py#L46

sentry-5810101850

Forward-Port-Of: odoo/enterprise#70001