*: pos_online_payment_self_order

Before this commit:
===============
- When paying with a QR code, the screen kept showing the QR code even after
the payment was completed.
- Closing the QR popup manually and performing another action resulted in
a `Finalize order` error.
- This happened because the WebSocket handler flow were not updating
the order state properly.

After this commit:
===============
- Ensure the frontend refreshes payment status directly from the server
when the current order is updated.
- Remove unnecessary synchronization calls to prevent stale state.
- The order is now correctly marked as paid, and no finalize error occurs
after closing the QR popup.

Issue:
===============
- The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION`
was fetching the full `pos.order` unnecessarily, because the order state is
already updated by another WebSocket flow.
- `notify_synchronisation` in the self order flow was redundant, as updates
are already handled in the `pos_self_order` module’s `pos.order` file.

Task - 5107009

Forward-Port-Of: odoo/odoo#229847

**Steps to reproduce:**
- Set your database in a language with a "," as a decimal separator, such as French
- Make a purchase, chose a payment method
- Before paying, click any +10/20/50 button
- The price will be multiplied by 100, then add the desired amount

**Why the fix:**
There were two places where the decimal separator was causing issues.

First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers.

Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number.

We now convert the numbers and the strings using the correct decimal separator.

opw-5126224

Forward-Port-Of: odoo/odoo#229735

Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added.

Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers.

opw-4896074

Forward-Port-Of: odoo/odoo#230004
Forward-Port-Of: odoo/odoo#216737

Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product.

> Setup of the Loyalty Program (Discount & Loyalty):
Program Type : Loyalty Card
Rule : minimum 5 items => 10 Loyalty Points per $
Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points

Steps to reproduce:
-------------------
* Open the pos Shop
* Select a customer with loyalty points
* Add a Simple Pen
* Click on * Reward > Free Product - Loyalty Program

> Observation:
Customer shouldn't 'win' points here
New Total is mathematically correct but not logic

Why the fix:
------------
We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points.

opw-4914774

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

Forward-Port-Of: odoo/odoo#231056
Forward-Port-Of: odoo/odoo#221570

### Issue:
The "Initial Balance" line in the General Ledger is not the first line with the "Load more" option

### Steps to reproduce:
- Accounting > Configuration > Accounting Reports > General Ledger
- Change the Load more limit in the options to a small number, i.e. 4
- Open the General Ledger and unfold an account with more than 10 lines
- There is no Initial Balance line, it appears when clicking "Load more"

### Cause:
The General Ledger query have this line `ORDER BY 2, move_name, 1`. Here 2 refers to the date and 1to the `account_move_line.id`. But the initial balance line has these columns equal to `NULL` so this ORDER BY will place it at the end of the results. When the limit is smaller than the total number of lines, the initial balance is not fetched by the query.

**Additional issue**
The limit is incremented several times. In our case, we set the option at 4. It gets incremented [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_report.py#L7172) because the load more option is triggered, and also [here](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L239) for no apparent reason (it is not needed "for the Initial balance"). So the query is called with `limit=6`, six lines are retrieved when clicking on "Load more". Considering a scenario where there are 10 lines for the account (with the initial balance) and "Load more limit" set to 4:
- The first query gets the lines 1-6 but only 1-4 are displayed.
- Clicking "Load more", the offset is 4, the query gets the lines 5-10. 10 being the initial balance, it is put in first position by [this piece of code](https://github.com/odoo/enterprise/blob/edb4ba5b98be9f9ae3617cc6e66c5e3376a1b56c/account_reports/models/account_general_ledger.py#L79-L91). So the lines displayed are 10, 5, 6, 7
- Last click on "Load more", offset is 8, query gets 9 and 10, displays 10, 9. In the end, one line is not displayed, and the initial balance is displayed twice.

### Solution:
Add `NULLS FIRST` in `ORDER BY` to always have the Initial Balance as the first line returned by the query.

Also remove the unnecessary `limit+1`.

opw-5105652