This commit adds the possibility for users to search and add mentions for
specific users for social networks.

This adds a new widget in social that implements this behavior.

This commit adds a new `mentions` text field to the social.post model that is
structured as a JSON object.
This field will contain for each social media_type as key, a dictionary that for
each mentionned name in the post has a specific value.
This value can either be a singular string, e.g. `Norbert: "albert"`, or another
dict, e.g. `Norbert: { "some_info": some_value, "username": "albert" }`.
This all depends on the needs of each media_type. e.g. for Twitter/X only the
username is needed to create a mention so we can only store a String.

But e.g. for Facebook, we need to store the ID of the page we are mentionning as
their mentioning system requires it. A valid mention for them would look like
`@[1234567] Page Name`, this means that the dictionary stored for it is
'{"facebook": {"Page Name": {"id": 1234567, "name": "Page Name"}}}'.

This also adds an option to the `instagram_image_ids` field in the template's form view.

It adds the option `accepted_file_extensions` to force the input the file to only accept .jpg and .jpeg images. These file extensions are the only ones that Instagram's API accepts to add to a post.

task-3801654

Since 2024, holiday pay recovery is calculated as a fixed 90% of the daily salary and is no longer capped monthly by the total debt. A final regularization is now performed in December or upon termination to balance the account.

- **Recovery Logic:** Updated the monthly recovery rule to deduct only 90% of the holiday pay amount without capping it by the `to_recover` balance.

- **December or termination Regularization:** Added new salary rules (`HolPayRegN`, `HolPayRegN1`) running only in December or upon employee termination to calculate the difference between the target amount and the amount actually recovered. The regularization is calculated proportionally to the holiday days actually taken.
  * Example: If an employee takes only 2 out of 10 accrued days, we regularize based on 1/5th of the full certificate amount.

- **DMFA Mapping:** Updated the DMFA report to dynamically assign the regularization amount:
  - **Code 12:** If further recovery is needed (Negative amount).
  - **Code 14:** If a reimbursement is due to the employee (Positive amount).
  - **Deterministic Grouping:** Ensured that employees grouped by NISS are sorted by ID during DMFA generation.


Task: 5419509

Before this commit:
====================
In the Master Production Schedule (MPS) view, the `Order` and `Duration` buttons remain visible even when there are no MPS records. It leads to a confusing user experience, as actions are shown while no records are available to act upon.

Steps to Reproduce:
====================
1. Install `mrp` module.
2. Go to Settings → Enable `MPS` option.
3. Navigate to MPS → Delete all MPS records → the `Order` and `Duration` buttons are still visible.

Additionally, when MPS records span multiple pages and the user deletes all records from current page, the view is not refreshed to redirect the user to another page that still contains records.

Cause of the issue:
====================
- The visibility of the `Order` and `Duration` buttons was not tied to the presence of MPS records. The logic did not check whether any MPS records existed, so both remains visible even when no MPS records were present.

After this commit:
====================
This commit ensures that `Order` and `Duration` buttons are hidden when there are no MPS records. Additionally, the view is refreshed after deleting all records from a page, ensuring the user is redirected to a page with remaining
MPS records.

TaskID-5356994

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/enterprise#106999

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#109548
Forward-Port-Of: odoo/enterprise#107233

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109128
Forward-Port-Of: odoo/enterprise#103130