Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740 (if this pr 212215 is merged then is not neccesary to merge the FW to master)

The goal of this pr is to see for which company belongs each sale/purchase tax in a product when more than one company is selected.

This pr solves odoo task #4829985 and this issue https://github.com/odoo/odoo/issues/147673

Steps to reproduce:

1) Go to runbot odoo enterprise 18 instance and select companies "My Belgian Company" and "My Company (San Francisco)" taking position in "My Belgian Company".

2) Go to "Accounting / Customers / Products" and get into product with name "Bolt" and internal reference "CONS_89957". There is shown two taxes in "Sale Taxes" and "Purchase Taxes" fields but is not possible to distinguish for which company belongs each tax.
![image](https://github.com/user-attachments/assets/c5da2fcd-c75a-458c-b6fc-a557e4221145)


Current behavior:
It can not be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Expected behavior:
It can be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Task Adhoc side: 51853


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

Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds.

As a reminder, the "is typing..." feature in discuss is implemented as follow:
- when typing, notify `is_typing: true` once every 50 seconds.
- when stop typing for 5 seconds, notify `is_typing: false`.
- other members assume stop typing if nothing received after 60 seconds.

This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow

```
- time: 0sec.   -> is_typing: true sent + received
- time: 50sec.  -> is_typing: true sent + received
- time: 60sec.  -> is_typing: false (assuming stop typing)
- time: 100sec. -> is_typing: true sent + received
```

This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing.

This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime.

runbot-223760

Issue:
-------------------------
In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically.

Steps to Reproduce:
-------------------------
- Create an MO for a lot-tracked product.
- Assign a lot number to the product, then remove the assigned lot number.
- Notice that the component is automatically marked as Consumed.

With this commit:
-------------------------
Previously, removing the lot number triggered an `onchange`, which called `_set_qty_producing`. This method auto-marked the component as consumed. As a result, users cannot re-reserve the components using the Check Availability button unless they manually uncheck the Consumed field.

This commit updates the logic to ensure that removing an assigned lot does not trigger component consumption. This allows users to reassign and re-reserve components smoothly in the production flow.

Task ID: [4797711](https://www.odoo.com/odoo/all-tasks/4797711)

[FIX] calendar_sms: calendar reminder event matching

The Issue
SMS reminders are sent to customers for calendar events regardless of whether they are scheduled for 1 hour before or 24 hours before; both reminders are sent.

Steps to Reproduce

1. Create two SMS reminders with different timings: one for 1 hour before the event and another for 24 hours before.
2. Create an attendee (since the calendar event administrator will not receive the SMS). Assign the attendee a phone number and an email.
3. Configure your SMS account to receive free credits (for local: create a SaaS and use its IAP token and UUID to link the IAP service).
4. Create two calendar events:
   - One that starts in 1 hour. (event_1h)
   - One that starts in 24 hours. (event_24h)
5. Add both reminders (1-hour and 24-hour reminders that we will call reminder_1h and reminder_24h) to each event and include the attendee you created. Accept the event invitation on behalf of the attendee.
6. Run the scheduled action that triggers event reminders.

Actual Behavior
For both events, both reminders are triggered.
for event_1h, reminder_1h and reminder_24h are sent.
for event_24h, reminder_1h and reminder_24h are sent.

Expected behavior:
For event_1h, reminder_1h is sent.
For event_24h, reminder_24h is sent.

Why Does This Happen?

After the SQL query, the result is a dictionary:

{"reminder_1h": "event_1h", "reminder_24h": "event_24h"}
(In reality, these should be IDs, but they are represented as strings for clarity.)

The code in the calendar_sms module retrieves all events from the dictionary, so we have a list with [event_1h, event_24h].
It also fetches the reminders that are in the keys of the dictionary (reminder_1h, reminder_24h).
Then it iterates through the events and for each event, checks if the reminders we have exist in the event.
If it exists, it sends an SMS.
(e.g., event_24h has both reminder_1h and reminder_24h linked to it, so it will send both reminders even if one states it starts in one hour, whereas it really starts in 24h).

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

Forward-Port-Of: odoo/odoo#207446
Forward-Port-Of: odoo/odoo#195782

Currently, loyalty cards with 0 points are being created for programs that have exceeded their max usage. Loyalty points are also erroneously being displayed for usage-exceeded programs when the tab is opened for the first time. And, it is not clear to the user when the max usage has been exceeded.

Steps to reproduce
-----
1. Create a loyalty program with a limited usage
2. Validate orders with the program up to the max usage
3. Refresh the tab and start another order with a new customer
4. Won points are still being displayed in the left pane
5. Validate the order, a loyalty card with 0 points is created

Cause
-----
Programs over the max usage are not being filtered out.

Fix
-----
Apply similar logic from https://github.com/odoo/odoo/pull/208134 and filter out programs over the max usage in `_get_program_ids()` Also, add the `total_order_count` to the form view next to `max_usage` so that it is clear that when the max usage is hit.
![image](https://github.com/user-attachments/assets/31055a3a-70ec-4547-85ed-662aac45014c)

opw-4744372

Forward-Port-Of: odoo/odoo#210507