AI-powered URL fetching now checks each website's robots.txt rules before accessing pages, using the Odoobot identity. This helps Odoo interact more politely with external websites, avoid disallowed content, and provide clearer feedback when access is blocked.

### Purpose
Add `robots.txt` compliance to the `_fetch_url` helper.  
Before fetching any URL, we now check the site's `robots.txt` and ensure that our user agent (`Odoobot/1.0`) is allowed to access the requested path.

### Changes
- Added `robots.txt` validation using `urllib.robotparser`
- Respect disallow rules for the `Odoobot/1.0` user agent

### Why
This ensures that our crawler behaves politely, avoids fetching disallowed resources, and provides more transparent failure reporting.

---
**Task-ID:** 4779962

Lithuanian payroll benefits are now managed as configurable payroll properties instead of fixed rule amounts. This gives payroll teams more flexibility to model employee benefits and helps ensure salary rules apply the right values in more complex payroll scenarios.

VoIP call handling has been improved so that each active call keeps its own state instead of sharing one global state. This reduces the risk of call mix-ups or timing issues when users perform attended transfers involving more than one simultaneous call.

The original VoIP code was written under the assumption that there would only ever be one session at a time. Consequently, much of the session state was stored in a global object called the UserAgent.

However, Odoo 19 implemented an attended transfer in VoIP, creating situations in which two sessions occur simultaneously. For this reason, the asynchronous code should no longer update session properties stored on the global UserAgent, as the session may have changed in the meantime, which could lead to race conditions.

This commit moves some logic from the UserAgent to the Session, and ensures all callbacks are properly mapped to the relevant session.

Forward-Port-Of: odoo/enterprise#95417

Belgian payroll now includes dedicated records for joint committees and their categories, making employee payroll setup more structured and aligned with local labor classifications. This helps businesses manage Belgian HR payroll information more accurately and consistently across employee records.

Website pages can now be served from a high-level cache when it is safe to do so, reducing page rendering time and database load. The change includes safeguards to avoid caching pages that may contain dynamic or sensitive content, such as session-related sales data.

This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to significantly improve performance by storing the HTML response of published pages, thereby reducing rendering time and database queries.

The management and logic for this cache are placed directly on the `website.page` model, as it is the source of the HTML response for these records. This approach makes it easy to control caching behavior through a few new, overridable methods:

-  `_allow_to_use_cache`: Determines whether a page is allowed to be served from the cache based on the current request, URL, or session. For example, a page with a `sale.order` in the session would not use the cache.

-  `_allow_cache_insertion`: Checks if the generated HTML content is eligible for caching. This is useful for preventing sensitive or dynamic content from being stored. For instance, a page with a reference to a `sale.order` would not be inserted into the cache.

-  `_post_process_response_from_cache`: A hook called after a response is retrieved from the cache. This method allows for post-processing, such as incrementing counters or modifying HTTP headers, without regenerating the entire page.

see https://github.com/odoo/odoo/pull/224487
see https://github.com/odoo/odoo/pull/88276

Forward-Port-Of: odoo/enterprise#94487

Changing a folder so it is not discoverable no longer automatically makes all documents inside require a direct link. This keeps folder-level visibility choices from unexpectedly restricting access to individual files, reducing confusion for users managing shared documents.

Changing the discoverability to not propagate to its children. Previously setting a folder to Discoverable to 'No' would result in all the files also requiring a link to access them, which is unwanted behaviour.

Task-4996667

Forward-Port-Of: odoo/enterprise#93697