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.

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