## Issue:
When you use the Smart button `Quality Checks` on a `stock.move` to validate QC, marking a test as Fail doesn't move the `stock.move` to the failing location even if the QC is now failed
This affects all quantity-based checks (Measure or Pass/Fail)

## Cause:
The `do_fail()` method marks the check as failed but does not call `_move_line_to_failure_location()`, so the move line stays in the original location

## Fix:
Trigger the failure wizard when failing a QC via the buttons
This allows the user to confirm the failure and select the appropriate failing location if multiple are configured

## Steps to reproduce:
- Enable Storage Locations in Settings
- Create a Product and a Quality Point (Product: Quality, Operations: Receipt, Control per: Quantity, Type: Measure, Tolerance: 0.0 to 1.0, Failure Locations: WH/Failure)
- Create a New Receipt for the Product and Mark as Todo
- Open 'Quality Checks' via the Smart button, select the QC, enter a measure value above the tolerance (e.g., 2.0), and click Measure.
- The QC should be marked as failed
- Before the fix, the details of the line in the Receipt doesn't change to the failing location
You can also do the same flow with a QP of type Pass/Fail and the Fail button

opw-4920391

Description of the issue/feature this PR addresses:

After a refactor, the month view no longer displayed homeworking locations as in previous versions. This PR fixes the issue and adapts the component using the updated version of the FullCalendar library.

Also fixes a small issue of when different locations with same icons are grouped together when they shouldn't

Current behavior before PR:

All days in the calendar month view displayed the 'Set location' button, regardless of whether a location record existed for the day or not.

Locations of a different type sharing the same icon (Office, Building 1...):

<img width="262" height="135" alt="before" src="https://github.com/user-attachments/assets/51745152-5f90-4917-9627-07aa0959eb3d" />

Desired behavior after PR is merged:

Locations are shown in the month view, and can be interacted with in the same way as in the week/day views, both for single and multicalendar:

<img width="1230" height="504" alt="multicalendar" src="https://github.com/user-attachments/assets/34108f57-2c25-400e-9fbe-106e2233c677" />

<img width="1232" height="382" alt="singlecalendar" src="https://github.com/user-attachments/assets/f4a0cf32-636f-49ce-a4cc-e53a9ac45643" />

Locations of a different type sharing the same icon:

<img width="256" height="132" alt="after" src="https://github.com/user-attachments/assets/643dd304-aeeb-48ec-abef-755e3eb5fdf0" />

---
Task ID: 5215931

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

## Versions
18.0 to saas-18.3
Fixed by 7b56a6afda919f3c09d08eb1256416e0a2b4b1d9 introducing a new logic with https://github.com/odoo/odoo/blob/26f9cab34a8cd594192d9e2a844494196b9ca5b6/addons/sale/controllers/product_configurator.py#L329

## Issue
Duplicating an attribute on a product leads to a traceback when adding the product to a SO.

## Steps to reproduce
*Ensure variants are activated in the settings*
- Create a new test product:
  - Attributes & Variants (on 2 distinct lines):
    - "Brand": 1;
    - "Brand": 2 & 3.
- Create a new SO:
  - Add the test product.

## Cause
The product has 2 attribute lines referring to the same attribute. As both attribute lines point to the same attribute, `ptals.attribute_id.read()` returns only one value for two ptals. The `zip()` call therefore drops the extra ptal, producing an incomplete mapping. When the configurator later tries to access this missing ptal entry, it crashes https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/sale/controllers/product_configurator.py#L321.

opw-5373672