[dnplkndll]

The analysis generated a noupdate_changes.xml for each of these and nothing
loaded any of them. A module update skips noupdate records by definition, so
those record changes only reach an existing database through an explicit
openupgrade.load_data call -- the upgrade ran green while delivering none of
them.

30 of the files reload a translatable field. That writes the source term and
nothing else, so the stale per-language translations keep the 19.0 wording and
Odoo serves those to every non-English user: the reload lands for English and is
silently undone for everyone else. Each of those load_data calls is paired with
delete_record_translations naming only the fields that record actually reloads,
derived from the 20.0 registry rather than guessed.

One change with one reason, which is the exception the playbook allows to
one module per PR.

---

CI: red until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). Not this branch:
base's pre-migration, which renames those two external ids, lives in #118 and
is not on 20.0 yet, so every branch cut from 20.0 alone hits it. Per the
fork's model the per-PR check is the lean one; the real migration gate is the
integration branch (#120), where all of this runs green over the full
585-module seed.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.

---

Scope correction

website_sale, hr_attendance, fleet and maintenance were in earlier revisions of this
branch and are no longer here: each has since grown a substantive migration script, so each
carries its own load_data call in its own PR (#167, #168, #169, #170) rather than in this
mechanical batch. 57 modules remain.