**Issue**
When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback.

**Steps to Reproduce**
1. Create an individual contact and link it to a company.
2. Create a Purchase Order with the individual as a vendor.
3. Create a Vendor Bill with the same individual as the vendor.
4. Try to perform Bill Matching.
5. A `ValueError: Expected singleton: res.partner(...)` is raised.

Video for reference:
https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view

**Root Cause**
Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error.

**Fix**
Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company.

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

Forward-Port-Of: odoo/odoo#226130

Context:
`\ufeff` characters are used in the editor to handle how the cursor behaves when
using arrow keys. In the case of knowledge comments, we want to have 2 cursor
positions at each comment boundary. I.e.: at the first beacon, we want a cursor
position before the anchor (outside of the comment), and one after (inside of
the comment).

Issue:
Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to
type inside, instead of 1 previously.

However knowledge comments beacons are not editable and only need one `zwnbsp`,
since we never want to type inside. Furthermore, having 2 and nothing in between
them would cause an issue when their content is normalized, which may lead to a
traceback:

- `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which
  merges 2 FEFF together. However the function `isZwnbsp` does return true for
  one text node with 2 FEFF characters. This means that during the next "add
  feffs" phase, new text nodes with one `FEFF` characters will be added,
  creating a growing loop generating new `FEFF` at every normalization phase.
- Furthermore, merging the nodes in one text node may not result in a new step
  in some cases, which prevent the `history_plugin` from registering the new
  node in time in its `nodeMap`, which may lead to a serialization traceback.

Resolution:
This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that
there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside.

[commit]: https://github.com/odoo/odoo/commit/f0eaeb6

task-5046068

Steps to reproduce:
-------------------
1. Enable self orderdering, and set an online payment method
2. Open 3 tabs: the main PoS one, the self order one, and the preparation display one (we have to setup the prep display too)
3. In the self order tab, make an order and pay for it

Observe that in the main tab, a receipt modal (window.print) appears, and the order is not sent to the payment display (on the third tab) until we either dismiss or accept the printing popup on the main tab.

Reason:
-------
If there is no printing device connected, we fallback to printing the receipt with `window.print`; this operation blocks the execution of the code that follows it, in our case sending the order to the preparation display, until we either dismiss or confirm the printing popup.

Now if the user is not paying attention to the main tab (only looking at the preparation display for instance), the order will not appear in the prep display.

Fix:
----
In the case of fallbacking to web printing, we execute the print in a `setTimeout`, so to not block the code that comes after it.

opw-5039685

Forward-Port-Of: odoo/odoo#225742