Steps to reproduce:
-------------------
1. Install account_winbooks_import, and switch to a Belgian company
2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"
3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable")
4. Confirm the import

The import fails with:
"You must select a receivable account for 'Tax Receivable Account'."

Why the issue
-------------
In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade".

This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after.

However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import.

Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again.

The fix
-------
Add back the same bypass originally introduced in 20804db6d87.

opw-6092464

Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back).

Steps to reproduce:
-------------------
* Open PoS with global discount and a gift card / eWallet program.
* Add a product (e.g. $100), apply a global discount (e.g. 10%).
* Apply a gift card for part of the balance (e.g. $50).

> Observation:
Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line.

Why the fix:
------------

`pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct.

opw-6104090

Forward-Port-Of: odoo/odoo#259577

When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on
`unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time.

This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models.

### speedup

In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model.

| Nbr linked unreconciled lines| Before PR | After PR | 
|:----------------------------:|:---------:|:--------:|
|              702             |    40s    |   3s     |
|              2000            |    40s    |   4.47s  |
|              10000           |    40s    |   11.28s |

Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch.

### memory

For the 702 unreconciled lines case, the memory consumption goes
 - 2.2 Gb -> 200Mb.

Forward-Port-Of: odoo/enterprise#115583