Before this commit, assignees of an automatically created recurring task occurrence never receive an assignment notification, unlike a manually assigned task.

Steps to reproduce:
1. Enable recurring tasks, create a task, assign it to user B, and set it to repeat (e.g. daily).
2. As user A, mark the task done so the next occurrence is created.
3. User B never gets an assignment notification for the new occurrence, even though they would if user A had assigned them manually.

This happens because `_create_next_occurrence()` creates the next task via `ProjectTask.copy()`. `copy()` sets `mail_auto_subscribe_no_notify=True` in its context to avoid spamming followers when a task is duplicated (e.g. the "Duplicate" button), but recurrence reuses that same `copy()` and inherits the suppression, so assignees of auto-created occurrences are silently skipped.

This commit fixes the issue by explicitly calling `_task_message_auto_subscribe_notify()` after copying the new task, with `mail_auto_subscribe_no_notify` reset to `False`. Thanks to this, assignees get notified like any other assignment, while normal manual copies keep their existing silent behaviour.

TL;DR
- we lose the measures from arch after a reload, if removed from activeMeasures

Step to reproduce:
- install pos, create few orders
- go to reporting> orders> switch to pivot view
- click the `Measures` dropdown,  `Order` is already selected
- untick it, then apply some filter so that view reloads (ex order date)
- reopen `Measures` dropdown, notice `Order` is missing form measures

Cause:
- view `view_report_pos_order_pivot` has `<field name="order_id" type="measure"/>`  in its pivot view
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/point_of_sale/views/pos_order_report_view.xml#L10
- `order_id` is M2O field
- Measure is compute from present `activeMeasure` and fields of type `["integer", "float", "monetary"]`
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/utils.js#L89-L120

- when the view is first loaded, `activeMeasure` all the fields with `type="measure"` which is directly passed to pivot's model as a metadata
https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_arch_parser.js#L59-L60

https://github.com/odoo/odoo/blob/f5c68cf0eb2ce6ec96dd4006b28466044af10e33/addons/web/static/src/views/pivot/pivot_view.js#L41
- when we toggled the `order_id` from measure and reloaded, `order_id` is popped from  `activeMeasure` and as it's field type is `many2one` it is not considered for `measures` in `computeReportMeasures`

Fix:
- maintain the measures from arch separately and feed it to `computeReportMeasures`

opw-6416196

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

Forward-Port-Of: odoo/odoo#278850

Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the write:

    [verifySteps] expected the following steps
    > Expected: [
      "web_save",
    ]
    > Received: []

This happens because a tap held longer than `LONG_TAP_DELAY` counts as a long press, and `_pointerUp` then dispatches no click at all. That delay spans the synthetic pointerdown and pointerup of a single `click()`, so the work a listener does during the press counts towards that delay: tapping save blurs the html field, which converts the whole editor content to inline styles, and under the load of a runbot build that conversion alone takes longer than the delay.

One solution could have been to raise `LONG_TAP_DELAY`, but a listener slower than the new value suppresses the click again.

This commit counts a tap as long only when the test releases the pointer itself, with `pointerUp`, so the work a listener does during a `click()` no longer suppresses the click.

https://runbot.odoo.com/odoo/error/946581

Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one:

    odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser:
    Error received after termination: [MEMINFO] tests done (after GC)
    - used: 220535896 - total: 341990868 - limit: 4395630592

Note that the figures themselves are fine (220MB used of a 4.4GB limit): the error is not about memory, only about when the line is logged.

This happens because the runner logs that line after `stop()`, and `stop()` is what reports the suite result: the server settles the test on that report and kills the browser. The final major GC outlasts the report. A passing build escapes because the browser dies within milliseconds; a failing one stays up for the screenshot, long enough for the GC to finish and the line to land after termination.

This commit fixes the issue by moving `stop()` after the final cleanups and their memory log: the [MEMINFO] line is still logged, but before the result report, while the server still waits on the browser.

https://runbot.odoo.com/odoo/error/229655

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

#### Description of the issue/feature this PR addresses:
Spanish amounts in words render "uno" where the grammar requires the apocopated "un" — on invoice PDFs, CFDI amounts, and anywhere num2words is called with a Spanish language.

#### Current behavior before PR:
"DOS MILLONES TRESCIENTOS UNO MIL CUATROCIENTOS TREINTA Y NUEVE PESOS 88/100 M.N." num2words applies the apocope only in to_currency(), never in to_cardinal(), and Odoo renders the plain cardinal then appends the currency label itself. Present in both versions pinned in requirements.txt (0.5.10, 0.5.13).

#### Desired behavior after PR is merged:
"DOS MILLONES TRESCIENTOS UN MIL CUATROCIENTOS TREINTA Y NUEVE PESOS 88/100 M.N."

The apocope is applied in to_cardinal() through the num2words monkey patches, for es, es_CO and es_VE. Other languages are untouched. Note: the cardinal is now always apocopated, so a standalone count reads "un" rather than "uno".

opw-6375677

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

Forward-Port-Of: odoo/odoo#277919