Description of the issue/feature this PR addresses:

In Odoo 19.0, format_amount(..., trailing_zeroes=False) removes
significant integer zeroes when the currency has no decimal places,
such as JPY. Project update monetary summaries use this formatter
with trailing_zeroes disabled.

Steps to reproduce in an Odoo shell with the default JPY configuration:

```python
from odoo.tools.misc import format_amount

currency = env.ref('base.JPY')
format_amount(env, 100, currency, trailing_zeroes=False)
format_amount(env, 0, currency, trailing_zeroes=False)
```

Current behavior before PR:

The numeric part of 100 becomes 1, and the numeric part of 0
disappears. Grouped amounts can also lose digits and leave an
incomplete thousands group.

Desired behavior after PR is merged:

Preserve all integer digits for currencies without decimal places.
Only strip trailing zeroes when a fractional part is present.

Regression coverage includes zero, positive, negative and grouped
amounts, both currency symbol positions, and languages with distinct
or identical decimal and thousands separators.

Validation:

- Before the fix: the new regression test fails in 20 subcases.
- After the fix: all 9 tests in TestFormatAmountFunction and
  TestFormatLangDate pass on an isolated PostgreSQL 16 database.
- git diff --check passes.

Test selection:
--test-tags=/base:TestFormatAmountFunction,/base:TestFormatLangDate


This PR also includes my signed Individual Contributor License

Agreement in doc/cla/individual/ysnkucuker.md.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#290374

Steps to reproduce:
- Create a gift card program and a gift card with some balance
- Open a PoS session, add a product to a new order and enter the gift card code: a reward line is added and the total decreases
- Refresh the page, or leave the order and take it back from the Orders screen

Issue:
The reward line disappears and the total goes back to the full price, while the server still holds the pos.order.line with `is_reward_line`, `coupon_id` and `points_cost`. Nothing warns the cashier, so the customer can be charged for a service already paid with the card.

Cause:
`_code_activated_coupon_ids` is a local field of pos.order: it is neither stored in IndexedDB nor sent to the server, so it is empty once the order is rebuilt on the client. `_updateRewardLines` deletes every reward line and only re-applies the ones whose coupon is found in `_code_activated_coupon_ids` or in `uiState.couponPointChanges`. `updatePrograms` only rebuilds the latter for programs detectable from the order content, so a gift card, eWallet or coupon card activated by code is never recognised again and its reward is dropped by the next `updateRewards` call (TicketScreen.setOrder, barcode scan, partner change, line added...).

In 17.0 `codeActivatedCoupons` was exported and restored with the order; the field became local with the 18.0 models rewrite.

Fix:
Add `_restoreCodeActivatedCoupons` on pos.order and call it from `checkMissingCoupons`, which runs once per rebuilt order (`setup` flags it with `invalidCoupons`) before the programs and the reward lines are refreshed. It re-links every persisted coupon referenced by a reward line that is in neither structure. Nominative cards are excluded so that removing the partner still drops their reward.

opw-6568849

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

Forward-Port-Of: odoo/odoo#290257
Forward-Port-Of: odoo/odoo#288102

Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to close then times out:

    FAILED: [8/36] Tour mail_template_dynamic_placeholder_tour
    Step Wait for the drop down to disappear
    (trigger: div[name="model_id"] .o-autocomplete:not(:has(.ui-autocomplete)))
    TIMEOUT step failed to complete within 10000 ms.

This happens because the search filling the dropdown runs 250ms after the last keystroke, so a suggestion of the previous search can be picked while the next search is still scheduled. Picking a suggestion only closes the dropdown. The scheduled search then runs, opens the dropdown on the selected value, and nothing closes it after that.

This commit fixes the issue by discarding the scheduled search when the dropdown closes.

https://runbot.odoo.com/odoo/error/233574
https://runbot.odoo.com/odoo/error/237744
https://runbot.odoo.com/odoo/error/944454
https://runbot.odoo.com/odoo/error/945517
https://runbot.odoo.com/odoo/error/947141

Forward-Port-Of: odoo/odoo#290317
Forward-Port-Of: odoo/odoo#287888

When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have side-effects like finding sibling fields in 20.0: in the code below, reading categories would fill roles.

```py
model_id = self.env["ir.model"]._get("test_new_api.foo")
fields = [{
    "name": "x_partner_id",
    "ttype": "many2one",
    "relation": "res.partner",
}, {
    "name": "x_role_ids",
    "ttype": "many2many",
    "relation": "res.partner.category",
}, {
    "name": "x_partner_category_ids",
    "ttype": "many2many",
    "relation": "res.partner.category",
    "related": "x_partner_id.category_id",
    "store": False,
    "readonly": True
}]
for f in fields:
    f["model_id"] = model_id.id
self.env["ir.model.fields"].create(fields)
env['test_new_api.foo']._fields['x_partner_category_ids'].relation  # should be None
```



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

Forward-Port-Of: odoo/odoo#290286
Forward-Port-Of: odoo/odoo#290067

#### Description of the issue/feature this PR addresses:
Rating a Starshipit shipment for an incomplete delivery address makes the whole rating loop fail instead of skipping that carrier. This breaks express checkout (Apple Pay / Google Pay), where the wallet only discloses a partial address before authorization: the customer gets "update postal address" and cannot pay, while manual checkout works.

#### Current behavior before PR:
delivery_starshipit is the only connector that rates a shipment without validating the addresses first, and it ignores the express_checkout_partial_delivery_address context key set by website_sale. The empty street is sent to /api/rates, which answers 200 with {"success": false, "errors": [{"details": "street parameter value is required"}]}, and _send_request turns that into a UserError. As starshipit_rate_shipment lets it propagate, it aborts the rating of every carrier instead of only this one, so no delivery method reaches the wallet. The same happens for errors only the api can report, such as invalid credentials.

#### Desired behavior after PR is merged:
Both the recipient and the warehouse address are validated before the api is called, as the other connectors already do, and the message is returned as an unsuccessful rate rather than raised. Starshipit requires the street, so a streetless address is still refused, but with a neutral message in the express checkout flow since the customer cannot complete it before paying. The Starshipit carrier is simply not proposed among the wallet's options, the other carriers are rated normally, and express checkout completes.

opw-6393393

Forward-Port-Of: odoo/enterprise#132515
Forward-Port-Of: odoo/enterprise#125117