This pull request introduces improvements to the handling of Chilean electronic document sequences, enforces stricter validation for certificate data, and modernizes string formatting throughout the codebase. The most significant changes focus on ensuring that document folio numbers are correctly managed in accordance with available CAFs, making the certificate model more robust, and updating code style for clarity and consistency.

This improvement is mostly made because CAFs have expiration dates and fixed folio numbers. If the expiration date is reached but the folios were not fully consumed, the system will try to generate a document with following number in the sequence but an error will be raised because that number belongs to an expired CAF, althought the user had already uploaded a new CAF.
To fix this, whenever the system looks for the highest number to set to a document, it previously check if that number is between the folio numbers of a valid CAF file.

### Chilean electronic document sequence management

* Added `_get_last_sequence` method to `account_move.py` to ensure that the folio number used for Chilean electronic documents (DTE) is valid and corresponds to an available CAF. If no CAF is available for the current folio, the sequence is reset using the document type's prefix and starting number.

### Certificate model validation

* Made `subject_serial_number` a required field in the `Certificate` model, enforcing that every certificate has a valid owner document and improving data integrity. We made this change to prevent the field being empty after loading the certificate in Odoo, since it is required by the SII to validate invoices.

This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

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

Forward-Port-Of: odoo/odoo#203409

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