Steps to reproduce
==================
1. Log in as an admin.
2. Go to any article and share with the portal.
3. Log in as a portal.
4. Open the shared article.
5. Press `Ctrl + P` or export from topbar.

Results showing `Export` and `Ctrl + P` works for which users:

| Version | Export        | Ctrl + P      |
| ------- | ------------- | ------------- |
| 17.0    | Admin, Portal | None          |
| 18.0    | Admin         | None          |
| 18.2    | Admin         | Admin         |
| 18.3    | Admin         | Admin, Public |
| 18.4    | Admin         | Admin, Public |
| Master  | Admin         | Admin, Public |

Technical
=========
In 17.0, `Ctrl + P` printed blank PDF because the required style assets
`knowledge.assets_knowledge_print` was loaded only on clicking `Export` button.

From 18.0, this asset was moved to the bundle `web.assets_web_print` to use
style for printing. Though this bundle is not loaded for portal and public users.

Note: For all versions, public users got the incomplete PDF on pressing `Ctrl + P`.

After this commit, we will load this asset bundle before printing.

Task-4797552

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

We optimize the retrieval of stock move lines by resolving a classic N+1 query bottleneck. In the previous implementation, the system performed a database search for every individual lot in the recordset. This refactor backports the batch processing pattern to fetch all necessary data in a single query, significantly improving performance for large data batches. 

This PR goes beyond just backporting the V18/19 logic by using python set logic instead of recordsets to ensure that that grouping logic remains O(n)

### Current behavior before PR:

The system uses a nested search pattern within a loop. A separate database request is triggered for every lot in the recordset. Performance degrades linearly as the number of lots increases, leading to slow processing times for large batches. 

### Desired behavior after PR is merged:

Logic is refactored into a single batch search on stock.move.line. Database overhead is reduced to a constant number of queries regardless of the recordset size. A defaultdict of python sets is utilized to map findings back to their respective lots. 

### Benchmarks

Profiling creation of purchase orders. Database has ~4200 stock.lot records.

| Before | After |
|---|---|
| 27sec | 7sec |  

### References

opw-5453842

Backported from: 99b39b72c7e65e85af6f06dcb6b02867623f3f69

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

Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`.

But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call.

This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com"

The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match.

Before this fix:
Create new record in System parameters with
key = "mail.catchall.domain.allowed"
value = "domain1.com, domain2.com,domain3.com"
-> after save, value == "domain1.com, domain2.com,domain3.com"

After this fix:
-> after save, value == "domain1.com,domain2.com,domain3.com"

OPW-5505414

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