Currently, On renaming or updating roles in the sign template doesn't get saved due
to which drag-drop 'Signature Item' is reseted back to 'Signer 1'.

**Steps to reproduce:**
1) Install sign app.
2) Open the Sign app and select a template.
3) Case A (Direct Rename): In the sidebar, rename a role from
   'Signer 1' to 'Signer 1-Test'.
4) Case B (Edit Button): Click the '3-dots' button on the role and click `edit`,
   change the name to 'Signer 1-Test', and save.
5) Drag and drop 'Signature Item' to template.

**Observed Behaviour:**
- The Role is not updated as `Signer 1-Test` and reset back to `Signer 1`

**Expected Behaviour:**
- The Role should be updated as `Signer 1-Test`.

## **Root Cause:**
### **Case A:** 
The `updateSignerNames` method(see[1]) checks `if (signer.name.includes(str))`
where `str` is `Signer` This condition evaluates to true for any custom name
containing that substring, causing the code to overwrite the user's custom input
with the default generated name string.

### **Case B:**
1) The method `updateRoleNameAndAvatar` see([2])  updated the local state `this.state.roleName`
   but failed to trigger the `onChangeRoleName` prop. As a result, the
   parent component (`SignTemplateSidebar`) remained unaware of the change
   and overwrote the name with its stale value during the next update cycle
   (triggered by the drag-and-drop action).

2) **when `sign_emsigner` module is installed:**
   The module patches `openSignRoleRecord` to manually set `this.state.roleName = data.name`
   before the role update process completes. However, `onChangeRoleName` relies
   on the condition `name !== this.state.roleName` to decide whether to notify
   the parent component (via `this.props.updateRoleName`). Since the state is
   already updated manually, this check fails (returns false), the parent is
   never notified, and the database is not updated. When `sign_emsigner` subsequently
   triggers a re-render (via `displayAddDocumentButton`), the parent passes down
   the old, state name, reverting the user's changes.

### **Fix:**
1) Remove all `updateSignerNames` logic since it is difficult to distinguish between a
   default-generated name and a user-customized name.

2) Update `updateRoleNameAndAvatar` to call `this.onChangeRoleName` with
   the new name, ensuring the parent component's state is synchronized.

[1]- https://github.com/odoo/enterprise/blob/382dd07b8ef93e9315963825e69066155a534ba0/sign/static/src/backend_components/sign_template/sign_template_sidebar.js#L92-L102

[2]- https://github.com/odoo/enterprise/blob/afc32de0a2757d8f241886ce27736fb7c07ab8c7/sign/static/src/backend_components/sign_template/sign_template_sidebar_role_items.js#L121-L122

**opw-5389063**

Forward-Port-Of: odoo/enterprise#102534

### Issue:
Due to this issue, `coupon_ids` which are never used are still shown in loyalty coupons history which is confusing for users.

#### Steps to reproduce:
1- Create two promotions:
   - Promo A: 10% discount
   - Promo B: 20% discount

2- Create a SO and add a line. Then confirm the SO.
3- Click on `Reward` button.
4- A dialog should show both promos. Discard the dialog.
5- Navigate to `Discount and Loyalty`.
6- Open Promo A and B and you can see both have lines with
   `coupon_id.order_id` = `created SO` which is confusing. `Issue 1`
7- Navigate back to SO. Click on `Reward` and select Promo A, apply.
8- Navigate to Promo B. As you see the the `coupon_id` related to
   the SO is still there. `Issue 2`

### Cause and Fix:
This is due to unlinking `coupon_ids` only in SO confirm action, causing this issue on already confirmed SOs:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/sale_loyalty/models/sale_order.py#L132-L136

We can fix this issue by `unlinking` the `coupons_ids` when a reward is applied or the dialog is discarded.

However there are 2 limitations:
1- The view needs to be updated. Otherwise, `coupon_ids` will not be deleted upon clicking on `discard` button. However the fix is still stable.
2- What if the dialog is closed with the cross button or the tab is closed without selecting a reward? In that case the issue will still persist.

To fix these issues, we can show only used `coupon_ids` in `loyalty_coupon_id` list view. However that cannot be done in stable as it requires `use_count` to be stored.
NB: With some complex filters this also could be fixed on stable but not worth it.

opw-5424753

Forward-Port-Of: odoo/odoo#245534

1) Printing a sahboard crashes, because `env.getStore` isn't defined since we're not in a spreadsheet context.

The `env.getStore` was needed to wait for cell animations that triggered when changing the mode to `dashboard` to print, but since here we already are in dashboard mode, no aimations are triggered and we don't need this check.

2) Only the first page is now printned in spreadsheet mode

This was because while waiting for the cells animations to end, the resize observer changed the sheetview size back to the correct size, instead of the print sheet size. We now change the size to the print size after waiting for the animations to end.

Task: [5502436](https://www.odoo.com/web#id=5502436&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#245195