[FIX] website: improve carousel accessibility
    
    To improve keyboard accessibility on carousels, the indicators container
    is not focusable anymore, and the indicators themselves now only have
    one focusable button at a time.
    The tab order is thus: previous button > active indicator > next button.
    (The previous and next button may both appear before.)
    You can still navigate among indicators with the left and right arrows,
    which also moves the focus to the newly targetted indicator.
    
    Note that other accessibility improvements remain to be done on the
    carousels (add a pause/play button on auto-sliding carousels, place the
    buttons before the carousel slide in the tab order, add some aria
    attributes (roledescription, live), adaptative labels...).

[FIX] website: make focus visible on carousel arrows
    
    When focusing manually (with tab / shift+tab) the previous/next arrows
    in carousels, it is hard to follow where the focus is, because there is
    no outline and the contrast is too small.
    
    This commit adds a specific outline if the button is `:focus-visible`
    (with both black and white to work on any background).

[IMP] website: pause carousel on focus within
    
    Carousels are paused on hover (or touchstart), but if the focus is
    inside one, it won't pause. That can make it hard to navigate within
    interactive carousels during the sliding interval (e.g. the dynamic
    products, which by default has 4 different products with 3 different
    focusable links/buttons).
    This commit applies the same behavior on focusin as Bootstrap's default
    on mouseover, and on focusout as on mouseout.

[IMP] website: support home/end keys on carousels

    When the focus is in a carousel, pressing the "home" key displays the
    first slide and pressing the "end" key displays the last slide.

task-5470023

Forward-Port-Of: odoo/odoo#266428
Forward-Port-Of: odoo/odoo#244939

## Issue
When logged in with a user who has the *Employee: Administrator* (`hr.group_hr_manager`) and the *User: Read his own attendances* (`hr_attendance.group_hr_attendance_own_reader`) groups, but not the *Officer: Manage attendances* (`hr_attendance.group_hr_attendance_officer`) group, the user won't be able to see their own attendance on their own employee's form view.

Additionally, a user without no Employee group but with the *Officer: Manage attendances* group could not see the attendance smart button on other employees form view.

## Steps to reproduce
1. Install *Attendances* (`hr_attendance`)
2. Set Marc Demo's groups:
    - *Employees: Administrator*
    - *Officer: Manage attendances*: unchecked
    - *User: Read his own attendances*: checked (implied by Role / User)
3. Log in as Marc Demo and open his own form in Employees
4. **The attendance smart button is missing, even though Marc Demo has the group to see his own attendance.**

For the second issue:
1. Set Marc Demo's groups:
    - *Employees: No*
    - *Officer: Manage attendances*: checked
    - *User: Read his own attendances*: checked (implied by Role / User)
2. Log in as Marc Demo and open another employee's form
3. **The attendance smart button is missing, even though Marc Demo has
the group to manage other employee's attendance.**

## Cause
There are two employee views defined in `hr_attendance`: `hr_employee_public_view_form` and `view_employee_form_inherit_hr_attendance`. The two views have different conditions under which the attendance smart button is displayed:
- In the public view, which is seen by users who do not have the *Employee: Administrator* group, the button is only displayed if the employee form is the one of the current user.

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_public_views.xml#L9-L15

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr/models/hr_employee_public.py#L119-L123

**This means that a user without the _Employee: Administrator_ group cannot see the attendance button of other employees, even with the _Officer: Manage attendances_ group.** This view should take into account the *Attendance Manager* group.

- In the other view, which is displayed for users with the *Employee: Administrator* group, the button is only displayed for attendance officers.

https://github.com/odoo/odoo/blob/b13d831e4c3c27ec7756302270f78c15f576a296/addons/hr_attendance/views/hr_employee_view.xml#L24-L29

**This means that if a user is an Employee Administrator, but is not an Attendance Officer, they cannot see their own attendance, even with the "own attendance" group.** This second view should take into account the _User: Read his own attendances_ group.

opw-6167399

Forward-Port-Of: odoo/odoo#263826

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
We have two conflicting css styling on mobile:
- `overflow-hidden` was added for mobile to avoid multiple scroll bars
- `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css

This means that the element is present at the bottom of the page, but we can't get to it manually.
When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top).

Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter.

**Fix:**
Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed.

original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd

opw-6061993

Forward-Port-Of: odoo/enterprise#118134
Forward-Port-Of: odoo/enterprise#113168

Before this commit, if the `_l10n_mx_edi_cfdi_invoice_append_addendas` method was executed more than once on the same invoice, the resulting CFDI would contain multiple `<cfdi:Addenda>` nodes.

This occurred because the method manually injects the new Addenda string at the end of the XML without checking if one was already present from a previous execution.

According to the SAT's Anexo 20 and the CFDI 4.0 XSD, the Addenda must be a single node and the last element of the Comprobante. Duplicating root-level nodes like `cfdi:Addenda` is a bad XML formation practice that can cause rejection by the recipient's automated systems.

This fix ensures the CFDI structure remains valid by:
1. Searching for an existing `{*}Addenda` node in the CFDI string.
2. Removing the old node before reconstructing the XML.
3. Preventing the string replacement logic from stacking multiple Addenda blocks.

This ensures that the CFDI remains clean and compliant with the official standard even if the process is triggered multiple times.

Forward-Port-Of: odoo/enterprise#109760

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#265491
Forward-Port-Of: odoo/odoo#251993

### Issue before this commit:
Opening the Purchase Matching wizard would crash if the vendor bill contained lines with a description and a Unit of Measure (UoM), but no product selected.

### Steps to reproduce the issue:
1. Enable Units of Measure in Settings
2. Create and confirm a Vendor Bill setting a description and a UoM, but leave the Product field empty.
3. Click on "Purchase matching" smart button
4. The system throws a traceback with the error: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure False defined on the product."

### Cause of the issue:
In the purchase.bill.line.match model, the field product_uom_qty was computed by calling _compute_quantity using line.product_uom_id. Since product_uom_id is a related field on product_id.uom_id, it returns False when no product is set. The UoM conversion logic cannot handle a False destination category, leading to the crash.

### Reason to introduce the fix:
Make purchase matching robust when imported vendor bills contain lines identified only by their description and not by a product. Note that for `purchase.bill.line.match` corresponding to an account.move.line but not related to any product, the `product_uom_qty` should match the quantity of the `aml_id` instead of attempting a UoM conversion based on a missing 
product UoM for the behavior to be consistent with the inverse method:

https://github.com/odoo/odoo/blob/59d6232979b8499fde6cb700df1870e2e38d0d3e/addons/purchase/models/purchase_bill_line_match.py#L45-L54

opw-5911526

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

Forward-Port-Of: odoo/odoo#266269
Forward-Port-Of: odoo/odoo#257827