fix(l10n_do_banks): create the UAE work entry types hr_work_entry_attendance needs

[erick-pcg]

Summary

Adds src/l10n_do_banks/19.0.1.0.0/pre-30-create-missing-core-work-entry-types.py, which
creates the three UAE work entry types that hr_work_entry_attendance references, so the
19.0 upgrade no longer aborts while loading the registry.

Validated on the ACINT staging build (odoo-acint-test-*), where it cleared this failure.

The failure

hr_work_entry_attendance is auto_install, so it installs itself as soon as
hr_work_entry and hr_attendance are present. Its
data/hr_attendance_overtime_rule_data.xml builds four overtime rules that point at UAE
work entry types through plain ref attributes, and none of those records carry
forcecreate="0". A missing target therefore aborts the whole registry:

ValueError: External ID not found in the system:
hr_work_entry.uae_work_entry_type_overtime_work_days_daytime

Three distinct types are needed, not one: the four rules reference
uae_work_entry_type_overtime_work_days_daytime, ..._nighttime and
uae_work_entry_type_overtime_off_days. Creating only the first one just moves the error
to the next rule.

Why the records are missing

The types are declared in hr_work_entry/data/hr_work_entry_type_data.xml, but that file
is only replayed when hr_work_entry itself is updated. On a database that
upgrade.odoo.com already brought to 19.0 with an older 19.0 source, the module sits at
installed with a current version (confirmed: 19.0.1.0), its data is never reloaded, and
the records never land -- while the newer odoo.sh source does ship the enterprise file that
needs them. base is not upgrading either, so
base/0.0.0/post-02-force-upgrade-installed-modules.py never runs to force it.

Why this approach

Three alternatives were ruled out by reading the loader, and are worth recording so they
are not retried:

• Marking hr_work_entry as to upgrade from a pre- script. The module graph reads
  ir_module_module.state once while it is being built (odoo/modules/module_graph.py),
  and every non-base package is already frozen by the time our scripts run. This is also
  why the base force-upgrade script works and an equivalent of ours would not.
• A migration script in one of our own addons. They all sit deeper in the dependency
  graph than hr_work_entry_attendance, so they run after the crash. Migration scripts also
  do not fire at all in init mode, and the module is being installed, not upgraded.
• util.update_record_from_xml. It requires a post- or end- script, by which point
  the registry has already failed.

That leaves a pre- script on l10n_do_banks, which has no dependencies and is therefore
processed at depth 1 -- before hr_work_entry. Raw SQL is required there because
hr.work.entry.type is not in the registry yet. Two column details the ORM would normally
handle: name is translated, so it is jsonb; round_days and round_days_type are NOT NULL
with no database default and are absent from the core XML, so they are copied off an existing
row instead of hardcoding selection values.

Notes

The script is idempotent: it checks ir_model_data first and turns itself into a no-op once
the records exist, so it stays harmless on databases migrated with an up-to-date source. The
ir_model_data rows are written under module='hr_work_entry' with noupdate=true, matching
what Odoo would have created, so a later hr_work_entry update finds them instead of
duplicating.

This is a patch over Odoo's own data. The underlying problem is upstream: the
hr_attendance.hr_attendance_overtime_rule_*_ae records have no forcecreate="0", which turns
a missing datum into a downed registry rather than a warning. A support ticket is still pending.

Odoo sources

odoo/odoo@e9d15ee
https://github.com/odoo/odoo/blob/19.0/addons/hr_work_entry/data/hr_work_entry_type_data.xml#L93-L115