Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.

## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
    - *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__

## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)

These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).

## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).

https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74

Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).

opw-6330790

Forward-Port-Of: odoo/enterprise#122147

Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.

It could lead to very obscure bugs such as:

```python
def some_innocent_code():
    category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
    incapacity_codes = category_dict['partial_incapacity']
    incapacity_codes |= category_dict['total_incapacity']
    # ... then use incapacity_codes

def print_rule_param():
    print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])

print_rule_param()  # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param()  # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```

The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.

task-6329380

Forward-Port-Of: odoo/enterprise#123057

### Steps to reproduce the issue:
1. Download Invoice and Debit Notes
2. Switch to another language
3. Go to an invoice (or create a new one)
4. Create a debit note for that invoice and print it or send it
5. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...'

### Cause of the issue:
This PR wants to fix c81be50733fcc9db5a3c903e7a571ce87c8f12bc. In that commit, the view inheritance used position="replace" to redefine the entire document title block. By doing so, standard strings like "Invoice" and "Invoice Date" were hardcoded directly into the account_debit_note view. Since these base terms are not exported to the translation files (.pot/.po) of the account_debit_note module to prevent duplication, Odoo fails to find their translations locally. Consequently, it ignores the existing translations from the base account module and falls back to displaying the terms in English.

### Reason to introduce the fix:
To restore the broken translations, we must avoid overriding the base XML nodes of the account module. Instead of replacing the entire block, this fix applies a minimal diff. This approach leaves the original base strings untouched, allowing Odoo's translation engine to successfully retrieve and apply the correct translations from the core account module.

opw-6341939

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

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#272172
Forward-Port-Of: odoo/odoo#259570

### Steps to reproduce:
- Download 'Sales' application
- From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card'
- From 'Products' > 'Gift cards & eWallet', Configure an eWallet program with a top-up product
- Have a customer with an existing eWallet balance
- Create a new sale order for that customer and add the eWallet top-up product
- Pay the order using the customer's eWallet
> The order gets discounted by the eWallet, effectively allowing the user to top up their balance
using the balance itself (infinite money glitch).

### Cause of Issue:
When computing the discountable amount for payment programs (like eWallets and gift cards), `_discountable_order` includes the total order amount. However, it did not exclude the program's own top-up products (`trigger_product_ids`) from the discountable lines.

### Fix:
If an order consists solely of top-up products, attempting to apply the eWallet now correctly raises a `UserError` ("There is nothing to discount").

opw-6341410

Forward-Port-Of: odoo/odoo#273419

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412

Forward-Port-Of: odoo/odoo#275528