[19.0][FIX] loyalty: clear stale mail.template.lang referencing removed _get_mail_partner

[dnplkndll]

What

Add openupgrade_scripts/scripts/loyalty/19.0.1.0/pre-migration.py to clear
mail.template.lang on the two loyalty templates (mail_template_gift_card,
mail_template_loyalty_card) when it still references the removed
loyalty.card._get_mail_partner() helper.

Why

In 18.0 those two templates stored lang as an inline template:

```
mail_template.lang = '{{ object._get_mail_partner().lang }}'
```

The helper was removed from loyalty.card in 19.0. The 19.0
mail_template_data.xml does not touch the lang field — so on
mode=update load, ORM template-syntax validation evaluates the stale
value against a loyalty.card with no _get_mail_partner and raises:

```
AttributeError: 'loyalty.card' object has no attribute '_get_mail_partner'
```

This aborts the migration at loyalty/data/mail_template_data.xml:3.

How

Single SQL UPDATE that clears lang only on the two affected templates
(identified by XML ID via ir_model_data) and only when lang still
contains _get_mail_partner. That preserves any customer customisation
that may have replaced the stock value.

Two related 18.0 stale references are intentionally not handled in
pre-migration because the 19.0 XML already overwrites them on load:

• mail.template.partner_to — reset via <field name=\"partner_to\" eval=\"False\"/>
• mail.template.body_html — fully rewritten in the 19.0 XML

The 19.0 design replaces explicit per-template lang/partner_to with
use_default_to=True, delegating recipient + language resolution to the
model at send time.

Test plan

• Repro confirmed: 18.0 DB with loyalty,sale_loyalty,pos_loyalty
  installed; -u all migration to 19.0 crashes as described without
  this patch.
• With this patch: migration completes cleanly. ir_module_module
  shows loyalty | 19.0.1.0 | installed. Post-migration the two
  templates have lang='', partner_to='', use_default_to=True
  — same state as a fresh 19.0 install.
• OCA CI green.

[pedrobaeza]

Good catch, but too many lines of code for something that can be very easy on post-migration scripts:

for xmlid in ("mail_template_gift_card", "mail_template_loyalty_card"):
    template = env.ref(xmlid, False)
    if template:
        template.lang = False

And you can reduce the comments done with AI to something less verbose.

[dnplkndll]

@pedrobaeza what do you think on the comments. in the past I would write the code fix and put the comment son the PR and never really but comments in the code. should there be any code comments? seems like they will just be obsolete and left later causing move confusion than good. but I do not recall reading any real convention on it.

[pedrobaeza]

Code comments should clarify the "why" or summarize the "what" of the following code block, but not being too verbose stating the obvious, nor letting doubts about why things are done.

In this case, a simple docstring of the method can be Reset "lang" field for these records, as they were set in previous version in XML, but not in this one, and Odoo doesn't reset non present fields. Short, concise, and pretty explanatory, don't you think?

[dnplkndll]

Thanks for the review. Force-pushed the refactor:

• Moved to post-migration.py (deleted the original pre-migration.py).
• Used your env.ref + record.lang = False shape, four lines of code.
• Stripped the file-level prose; reasoning stays in the PR description.

CI should re-run now.

[pedrobaeza]

You can put the docstring I recommended.