### Description of the issue/feature this PR addresses:

This PR optimizes the XLSX export process for large accounting reports by implementing a "smarter" batching strategy. 

Three months ago, a batching mechanism was introduced to prevent memory errors during large exports. However, that implementation batched every single account individually. While this solved the memory consumption issue, it introduced a significant performance regression: processing thousands of tiny batches one-by-one is extremely slow due to the overhead of repeated report engine calls. 

This change introduces a weighted batching system that groups multiple accounts together into a single batch until a maximum line threshold is reached. This strikes an ideal balance between low memory usage and high execution speed. 

### Current behavior before PR:

The system uses _get_accounts_with_move_lines to retrieve a list of accounts. The export logic iterates through every account individually, creating a separate batch for each one. For reports with many accounts (even those with few moves), the overhead of calling the report engine for every single account causes the export to take an excessive amount of time. Memory usage is low, but time performance is poor.

### Desired behavior after PR is merged:

The new _get_account_ids_and_weights_with_move_lines method fetches both the account IDs and the count of moves (weight) associated with them in a single SQL query. 

The _build_account_batches method packs accounts sequentially into batches of up to 500,000 lines. Small accounts are grouped together. Large "mega-accounts" that exceed the limit are isolated into their own batches to prevent memory spikes. 

_get_accounts_with_move_lines is deprecated. It is effectively superseded by the more informative weighted query, providing the data necessary for the smarter partition logic.

### Benchmarks

| # Move Lines | Before | After |
| --- |---|---|
| ~5.6million | Times Out | 32sec |  
| ~3.5million| Times Out | 11sec | 

### References

#103329
opw-6077972
opw-5723374
opw-5950806
opw-5915227
opw-6066290
opw-5914983


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

### Issue:
The mega menu position is inconsistent between the two "Sub Menus"
options.

With "On Click", the mega menu opens below the navbar, which is its
default position. With "On Hover", it opens directly below the mega menu
toggle, making it visually misaligned with the "On Click" behavior.

### Reason:
The different positioning for "On Hover" was intentional. If the mega
menu were placed in its default position, the gap between the toggle and
the mega menu would cause the cursor to briefly leave both elements
while moving between them, unintentionally closing the mega menu. To
prevent this, the mega menu was positioned directly below the toggle,
removing that gap.

### Fix:
Restore the mega menu to its default position for "On Hover" to match
the "On Click" behavior.

To prevent the original issue of the mega menu closing while the cursor
travels from the toggle to the mega menu, introduce an invisible hover
bridge. The bridge is implemented as a pseudo-element of the mega menu
toggle, ensuring the cursor never leaves the hover area while crossing
the gap.

For header templates, such as "Menu - Sales 1" and "Menu - Sales 4", the
hover bridge overlaps interactive content in the navbar. To avoid this,
position the mega menu below the menus container instead of below the
navbar for these specific headers in both "Sub Menus" options.

This results in a consistent mega menu position while preventing
unintentional menu closure during cursor movement.

task-[6116253](https://www.odoo.com/odoo/project/974/tasks/6116253)

Co-authored-by: Arib Ansari <aans@odoo.com>



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

### Issue before this commit:
When generating an electronic invoice (e.g., ZUGFeRD/Factur-X) with a 0% tax from a non-EEA supplier (e.g., Switzerland) to an EEA customer (e.g., Germany), the XML tax <ram:CategoryCode> is incorrectly set to 'E' (Exempt) instead of 'G' (Export).

### Steps to reproduce the issue:
1. Download Accounting and l10n_ch
2. Set the VAT for the CH company
3. Create an invoice for a German customer with 0% tax setted (for which you have to set as electronic invoicing the ZUGFeRD template into the Accounting tab of his contact)
4. Send it and see that the tag <ram:CategoryCode> is setted as E instead of G

### Cause of the issue:
The logic assigning the 'G' and 'K' tax category codes was only triggered if the supplier was located within the EEA. If the supplier was outside the EEA, the code bypassed this block entirely and fell back to the default 'E' code for 0% taxes.

### Reason to introduce the fix:
Update the condition to trigger when either the supplier or the customer is in the EEA. This ensures that cross-border transactions involving at least one EEA party correctly evaluate and apply the 'G' (Export outside the EU) category code.  Also the case supplier not in eea with VAT filled in + customer in eea + RC tax with amount != 0 is fixed now (letter G reported instead of S).

### Documentation:
[eInvoicing technical guidance document_v1.pdf](https://github.com/user-attachments/files/30831749/eInvoicing.technical.guidance.document_v1.pdf)


opw-6407399

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

#### 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

**Steps to reproduce:**
1. Install Accounting
2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments)
3. Test the imported records

**Issue:**
- `RecursionError: maximum recursion depth exceeded`.

**Cause:**
- In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`.
- While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`).
- By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop.

**Fix:**
1. Revert the assignment iteration back to `for line in self:`.
2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`.

By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion.

opw-6451854