**Steps to reproduce the bug:**
- Enable multi-step routes in the general settings.
- Go to the warehouse settings:
    - Select 3 steps for Outgoing Shipments.
- Create a storable product “P1”.
- Create a sales order with the following details:
    - Customer: Azure Interior
    - Product: 3 units of P1
- Confirm the sales order

- Go to the pick picking
- Set the quantity to 1 unit
- Validate the pick and create a backorder
- Go to the pack step and validate it

- Return to the pick backorder and validate it for 2 units
- Create a return from this backorder
- Validate the return
- Go back to the sales order

**Problem:**
The delivered quantity is set to -2 instead of 0. When the return is validated, the “_compute_qty_delivered” function is triggered, which uses both outgoing and incoming moves. The “_get_outgoing_incoming_moves” method is called to retrieve these moves. However, for return moves, we only check if the `location_dest` is not set to customer usage and if `move.to_refund` is not false, without verifying that the source location is from the customer.

opw-3962062

Currently, you cannot merge partners if they have bank accounts linked to payments.

### Steps to reproduce

* Install the `account` module.
* Create two partners having the same bank account number.
* Create and post payments for each of those partners.
* Attempt to merge those partners.

You should be met with the following message:
```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Journal Entry (account.move)
Constraint: account_move_partner_bank_id_fkey
```

### Cause
When merging partners, the system attempts to update all foreign keys referencing the partners being merged. In certain circumstances, this update violates unicity constraints. In such cases, the system simply deletes the records that can't be updated.

In our case, the `res_partner_bank` table has the following unicity constraint: `unique(sanitized_acc_number, partner_id)`. When we merge the two partners and the system attempts to update the `partner_id` field on `res_partner_bank`, the constraint is violated because both partners originally had the same account number. The system then tries to delete those bank accounts, but it fails because they are linked to payments (with an `ondelete restrict` clause).

### Fix

Identify the bank accounts that are duplicated between the source and destination partners, and merge them before merging the partners.

opw-3925952

Before this PR, redirecting the user to a page that would then be
rewritten according to the user's preferred language would make the
chatbot loop.

Steps to reproduce:
- Install website_helpdesk_livechat
- Install another language and translate the website
- Modify the /contactus rule to use the helpdesk live chat
- Create a question step that redirects the user to `/helpdesk/customer-
care-1`
- Navigate to the contactus page and change the website language to the
newly installed language
- Start the chatbot and proceed to the redirect step
- The chatbot gets stuck in a loop

This happens because the chatbot checks if the redirect link and the
URL are the same to determine if the redirection was already done.
However, since the URL is rewritten, it assumes it wasn't done and
redirects once again.

When a page is reloaded, the chatbot starts where it left off.
However, it should check that the step was not already processed
beforehand. This PR fixes this issue by skipping the already done
step.

opw-3987426