Before this commit, when debug mode was activated, and we wanted to deactivate (by the debug menu, the command pallet or the settings links), the debug mode wasn't completely and correctly deactivated. The debug mode was removed from the URL and the debug menu wasn't accessible anymore, but not everything was deactivated. For instance : the settings were still there (Translations, Gamification Tools and Technical), the link tracker app is still visible, all the user technical rights and extra rights are still shown.

The issue occurs, because we just remove it from the URL (to setting the debug to `undefined`); this will remove the debug menu, but won't deactivate correctly the debug mode. To deactivate correctly the debug mode, the debug should be set to `0`;

Note that, this commit will also solve a minor issue, that when activate the assets debugging, or test assets debugging from the debug menu, the rest of the query string was lost. This could lead to some errors, when reloading do to lost information.

opw-4042335
opw-4047116

## Issue:
- When multi-step delivery is enabled, validating then issuing a partial or full return on the first step (E.G. WH/Stock to WH/Output) results in negative values on the SO delivered quantity field.

## Steps To Reproduce:
- Enable multi-Step routes in settings.
- Go to warehouses and on the main Warehouse set Outgoing Shipments to "Send goods in output and then deliver (2 steps)"
- go to a product category and set up the 2 steps route on it.
- create a SO and select a product with a quantity more than 1 from the category save then validate
- the first delivery will appear (from WH/Stocl to WH/Output)
- Validate it and then press return and either fill a partial or full return.
- go back to the sales order page you will notice the the delivered quantity is negative of what was returned on the previous step which is wrong.

## Solution:
- The strict mode in sale_stock's `_get_outgoing_incoming_moves` method only considers moves strictly delivered to customers. Despite calling this method with strict=True in `_compute_qty_delivered`, the issue persisted.
- The problem was identified at the end of `_get_outgoing_incoming_moves`, where the method incorrectly accounts for returns. It checks that the return destination's usage is not "customer" but fails to verify if the source is "customer."
- Added a condition to ensure that the source location's usage is "customer" for return moves.

opw-3933009

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