This PR addresses a bug introduced in the PR https://github.com/odoo/odoo/pull/277276
To reproduce the bug:
1- Produce a serial tracked product with serial number 00001 for example.
2- Set MO to progress.
3- Clear the lot_producing_ids, and generate a new one 00002.
3- Produce again.

= The MO produces a product with the old serial number 00001 instead of
00002.

This happens because while producing the MO, it finds the move already has its own lot_ids but we need to check it's different than the `lot_producing_ids` generated on the MO to re-assign it again.

Side improvement:
The button `Generate Serial` is now named `Generate Serial Numbers` and becomes `Edit Serial Numbers` whenever there are already multiple generated serial numbers on the MO.
This is more relevant to the user now since they now have the ability to set a done MO to progress and change the quantity to produce hence, it makes sense to edit the serial numbers when they are asked to specify a serial number in that case.

Problem:

The Disconnect button showed on every account holding a token, so manually configured accounts got it too. Pressing it tells Meta to stop sending messages to the database, then fails while clearing the token, which a manual account needs, so Odoo rolls back while Meta does not. The account keeps looking configured and incoming messages stop, and there is no way back from the interface, Meta only allows re-subscribing through the API.

The button relied on `show_disconnect`, a computed field reading `token`, which is restricted to WhatsApp administrators while every internal user has read access on `whatsapp.account`. Opening the account form as a regular user therefore raised an AccessError.

Solution:

Restrict the header to WhatsApp administrators and test the account fields directly in its `invisible`, which hides the button on manual accounts and removes the need for the computed field.

Add a safety check on write access in `button_disconnect`. Hiding a button only removes it from the screen, the method stays callable over RPC, and the request to Meta happens before the write that would have been refused.

Task-6544628

Forward-Port-Of: odoo/enterprise#130759

When a user mentions the wrong partner and corrects it by continuing to type, e.g. picking "John" by mistake, typing further so the text becomes "@ John Doe" and picking "John Doe" in the suggestion popup, the discarded first pick stays in the composer's mentioned partners. On post, mentions are validated by searching the body for "@<name>", and "@ John" is found inside "@ John Doe", so the partner the user tried to replace is kept in the recipients and gets notified even though no mention of them remains visible in the message.

Validate mentions from the longest mention text to the shortest, counting the occurrences of each text and blanking them out before looking for shorter ones. A partner whose mention text only appears inside a longer mention is dropped, while distinct partners sharing the same name each consume one occurrence.

Steps to reproduce:

- Create contacts "John" and "John Doe"
- On any record, open the chatter and type "@John", pick "John" by mistake, then keep typing " Doe" and pick "John Doe" in the suggestion popup to correct it
- Send the message

=> The message is also sent to "John" although only "@John Doe" appears in the body.

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

Forward-Port-Of: odoo/odoo#287267
Forward-Port-Of: odoo/odoo#284239

Problem:
A time off request is saved with a duration of 0 days instead of 1 day
as soon as an automation rule on Time Off has an action that creates an
activity.

Cause:
`_compute_field_value` runs the actions while the fields of the
computation it wraps are still protected and not written yet. On
`hr.leave` the actions run from a computation nested in
`_compute_date_from_to`, so `date_from` is empty when the activity
notification reads `display_name`, and `_compute_duration` stores 0.
Setting `date_from` afterwards does not mark `number_of_days` to compute
again since it is protected.

Solution:
Extract the snapshot `_filter_pre` already does into `_keep_to_compute`
and wrap the post filter and the actions with it, so the fields
depending on the running computation stay to compute. Same treatment as
488419a5ca49 (odoo/odoo#243611) on the pre filter.

Steps to reproduce:
- Enable the developer mode.
- Go to Settings > Technical > Automation Rules and create a rule on the
  Time Off model with the trigger On create and edit.
- Add an action of type Create Activity, set its Responsible to another
  user, and save.
- Go to Time Off > New, pick an employee and a time off type, and
  request one working day.
- Observe that the request shows a duration of 0 days.

Ticket [link](https://www.odoo.com/odoo/project.task/6498783)

opw-6498783

Forward-Port-Of: odoo/odoo#287536
Forward-Port-Of: odoo/odoo#286791

## [FIX] voip: one registration binding per softphone window
Asterisk identifies a registration binding by its Contact URI alone: the
registrar compares candidates with pjsip_uri_cmp() and names the stored
object after the MD5 of that URI. Neither `+sip.instance` nor `reg-id` is
consulted, RFC 5626 section 5.4.1 not being implemented on the inbound
registrar side. Every window of a user therefore advertised the same
Contact and collapsed into a single binding, so only the last one to
REGISTER could be rung - across tabs and across devices alike.

The discriminator has to be a URI parameter rather than part of the user
part: res_pjsip_path.c matches the user part against the AOR name to
decide whether to attach the edge proxy's RFC 5626 flow-token Path, and
without that Path an inbound INVITE cannot be routed to the browser at
all. Parameters after the host are ignored by that lookup yet do make two
URIs compare unequal, so `x-odoo-unique` buys distinct bindings at no cost
to the Path.

It is assigned once per user agent instead of being computed in the
configuration getter, so that reading the configuration twice cannot yield
two different Contact URIs.

## [FIX] voip: restrict voip.extension range
Before this commit:
- voip module validates against voip.extension number length: between 100 and 99999
- phone service configures tenants to allow extensions between 10 and 9999

As there is a discrepancy between those 2, we decided to allow
the ranges that overlap between both parts.

So, after this commit:
- voip module allows extensions numbers between 100 and 9999.

Rationale
We decided to remove the 5-number range on that part instead of adding it in the phone service part, because:
- 9900 extension numbers is plenty enough and it can lower a bit the complexity of the asterisk dialplan,
which makes the asterisk dialplan regeneration more lightweight
- it is easier to add a range in the future than remove one, due to migration nightmare

When registering a payment (e.g. through the payment register wizard), the mandate was not always linked to the created payment, leaving `mandate_id` empty and breaking SEPA direct debit flows(`account.direct.debit.mandate()` instead of the expected mandate).

During `create`, the `_validate_mandate_id` constraint reads `needs_mandate_of_type`, a non-stored computed field. Its computation triggers a recompute of `payment_method_id`, which re-enters the same constraint while `needs_mandate_of_type` is still being computed. The ORM then protects the field: reading it returns a bogus `False` and caches it. `_compute_mandate_id` consumes that poisoned value and permanently stores an empty `mandate_id`, since its actual dependencies never change afterwards. 

Fix: make `_compute_needs_mandate_type` and `_compute_mandate_id` depend on `payment_method_line_id` instead of `payment_method_id`, so mandate is computed without reading a field that can be in a protected context. 

note: I was only able to replicate the runbot error through testing, and not through web ui/functionally.


runbot-error-946999
runbot-error-947001
runbot-error-947010
runbot-error-947011
runbot-error-947012
runbot-error-947013
runbot-error-947014
runbot-error-947015
runbot-error-947016