### Steps to reproduce:
1. Open any Project > open its Tasks view
2. Open Studio
3. Press the browser Back button

### Current behavior:
Crash "active_id is not defined". The Tasks view needs active_id
(the ID of the open project, e.g. 5) to pre-filter tasks by project,
but it is missing when Studio restores the view from the URL.

### Expected behavior:
Back exits Studio and returns to the Tasks view with no error.

### Issue:
The browser URL tracks navigation as a stack of visited actions. When
Studio is open, the stack has two entries: the view being edited
(position -2) and Studio itself (position -1). Studio loads the action
from position -2 but was reading active_id from position -1 Studio's
own slot, which carries no record ID. Reading context from the wrong
slot left active_id undefined, crashing the view render.

A second problem: Studio was writing active_id into the shared URL
state. The router automatically copies this into the Studio URL path,
changing ".../tasks/studio" to ".../tasks/5/studio". Every Back press
produced a different URL, so the router treated it as a new visit
instead of a Back navigation creating an infinite history loop.

### Fix:
active_id now comes from the same URL slot as the action identity
(position -2), which is where the project ID actually lives. The
shared URL write that caused the history loop is removed.

task-6097949

In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started.

Case 1:
- Have website A and website B
- Create an appointment page website A
- Log in via website B
- As public user, make an appointment in Website A
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url.
This parameter is then used as fallback when we need to retrieve the base url without an active record

Case 2:
- Have website A and website B
- Create an event and assign it to website B
- As public user, access the event and register to it
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event.
This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A)

Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf

opw-4146760
opw-4336369

Forward-Port-Of: odoo/enterprise#123851
Forward-Port-Of: odoo/enterprise#122669

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

task-6215466

Forward-Port-Of: odoo/enterprise#122313

# How to reproduce
- Set an employee's work schedule to flexible 40hrs/week with 8hrs of work per day
- Create a new attendance for that employee that :
	- Is the very first attendance of that employee
	- Is not on a monday (e.g. a Friday)
- Create a second attendance for that employee that :
	- Is atleast one week after the first attendance
	- Is one of the two days of the week before the day of the week of the first attendance (e.g. a Wednesday or a Thursday)
- Go to the settings, update the value for "Tolerance Time In Favor Of Company" and save
- Come back to the second attendance

# The problem
The Extra Hours have changed and are equal to the worked time

# Cause
When we update the tolerance time, we recompute the overtime of every attendance of every employee.
In this recomputation, we compute the `expected_attendance` of every employee and transforms
them into a dict of the expected working time for each day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L349-L356

Later, if an attendace of the employee was not in their expected working days, then we consider that all hours worked were overtime :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L381-L384

This makes sense but our issue is that days in the middle of the week are considered "time-off" when they
should not. That's because for flexible working schedules, we emulate the expected working hours based on
the total hours per week and the maximum hours per day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/resource/models/resource_calendar.py#L384-L386

For every "week", we start from the first day and continue forward by greedily using all hours for that
day until there is no more hours for the week. The problem is that since this PR, we don't start "weeks" on
mondays, but on the `start_datime` :
https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

And in our case, `start_datetime` is the very first attendance day of the employee :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L344

So our expected working days are desynched with the days of the week

# Proposed solution
We partly revert https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

opw-6289079

Forward-Port-Of: odoo/odoo#269820

**Purpose of this PR:**

Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages.

<img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" />

Steps to reproduce:

1. Open Voice & Video Settings.
2. Start the Voice detection sensitivity test.
3. Quickly click Stop immediately after clicking Test.
4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level.

> [!NOTE]
>  this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt.

This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it.

This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped.

**Steps to reproduce:**
- activate subcontracting in the settings
- create a storable product 'comp' with categ 
avco auto
- confirm a PO and validate receipt for 1 comp 
at 10
- create a storable product 'prod' with categ 
avco auto
- in the purchase tab set a vendor with a price of 30 
- create a subcontracting bom with the same vendor as
as the subcontractor and 1 quantity of our comp 
products in the components
- confirm a PO for 1 prod with the subcontractor
as the vendor
- on the receipt, click on 'record component and change the 
'quantity' to 2 then click on record production (you might need
to click anywhere on the form to have the 'record production' 
appear)
- validate the receipt
- create and confirm the Bill for the 2 quantity
- open valuation view

**Current behavior:**
an extra stock valuation layer was created with 
no quantity, no reference and a total value of 20

**Expected behavior:**
This extra layer is not needed, the two svl 
for the receipt are made with a quantity of 2 
and so is the bill, so the amls created are as follow : 
- svl comp : 
  -  credit 20 stock valuation 
  - debit 20 cost of production 
- svl prod : 
  -  debit 80 stock valuation
  - credit 60 stock interim received
  - credit 20 cost of production
- amls from the bill : 
  - 60 stock interim received
  - 60 account payable 

After all of this the result is : 
debit 60 in stock valuation 
credit 60 account payable 
which is what we want 

The extra layer is not needed and creates 
unbalance, its amls are : 
credit 20 stock interim received
debit 20 stock valuation

**Cause of the issue:**
This extra svl comes from the 
_apply_price_difference() method 
https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/purchase_stock/models/account_invoice.py#L131
This method creates svl and/or amls 
to compensate difference between the bill 
price and the PO price (see https://github.com/odoo/odoo/pull/126536 for more details)
To check if there is a difference, we compute 
the layer_price_unit 
https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/purchase_stock/models/account_move_line.py#L140
and pass it as parameter to _prepare_pdiff_vals()
https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/purchase_stock/models/account_move_line.py#L159
were it will be compared to the aml price 
https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/purchase_stock/models/account_move_line.py#L239-L244
 
In the case of a subcontracted product, price unit of 
the bill (30 in our case) should be the price unit of the svl of the 
subcontracted product (40) - the price of the comps 
for one unit of the subcontracted product (10). 
That's why when we call _get_layer_price_unit, there is a 
mrp_subcontracting_purchase override to remove 
the component price from the svl of the subcontracted
product.
https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/mrp_subcontracting_purchase/models/stock_valuation_layer.py#L18-L20

To get the price of the components for on unit of the 
subcontracted product, we divide the value of the 
components svls by production.product_uom_qty, 
but that is not necessarily the same number as the 
quantity of the svl of the subcontracted product 
(in most cases yes but not in the case of our steps to 
reproduce for instance). 

In terms of account move lines  the quantity of the svl 
is the one that maters so that's the one that we should 
take into account also in this computation. 

opw-6191829

Forward-Port-Of: odoo/odoo#271467

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#273129