Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its capacity to generate new CNPJ numbers. The current, exclusively numeric model is approaching its limit. The transition to a format that includes letters and numbers expands the number of possible combinations, ensuring the future availability of registrations for new companies. With the government expanding the CNPJ numbers, we need to implement a solution to support the alphanumeric CNPJ that will be issued starting July 2026.

Current Behavior: The method, `is_valid,` from stdnum is currently used to determine whether the CNPJ is valid or not. This is now considered an outdated method to determine the validation.

Changed Behavior: The new validation logic by stdnum, found here https://github.com/arthurdejong/python-stdnum/commit/d3ec3bd7fefe0d0a708b6594a66de28777eb9b8d, is patched into `check_vat_br.` The reasoning for patching this rather than calling stdnum is because using stdnum will cause library dependency issues for older versions of Odoo.

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

Forward-Port-Of: odoo/odoo#262939
Forward-Port-Of: odoo/odoo#260516

Previously, computing warning_employee_rate fetched all analytic lines associated with projects.task_ids to check if any employee lacked a sale_order_line in project.sale.line.employee.map.

This approach had two major flaws:

	1- Iterating over all accessible tasks is highly inefficient for
	large projects, especially since many tasks do not even have
	associated analytic lines.

	2- Fetching analytic lines blindly by task_id could pull in lines
	linked to a completely different project_id adding performance issues.

**Solution**:
Since the compute method for the `project_id` field for the `account.analytic.line` model is making sure that the field `project_id` equal the project for the task, then we can remove the domain matching for the `task_id`.

We now can replace the `_read_group` with a simple SQL query, filtering out the unmapped projects directly.

The benchmark done below was on a database that had around 10M analytic lines, 2K `project_sale_line_employee_map` records and 1M tasks with the top 80 projects in terms of the number of `analytic.lines` + projects that had the most records in the `project_sale_line_employee_map`.
| Before | After |
| :--- | :--- |
| 33.0s | 170.0ms |