### Analysis

Planning schedule computation may merge intervals coming from two different sources.

Fully allocated Planning slots reuse intervals from the employee working schedule, whose payload is a `resource.calendar.attendance` recordset. Partial allocations, however, create synthetic intervals using a `resource.calendar` recordset.

When such Planning slots overlap, these intervals are merged into the same `Intervals` instance. This can raise a `TypeError` while sorting or merging the interval payloads, since recordsets from different models cannot be combined.

This can surface during attendance creation or deletion when overtime recomputation requests the employee Planning schedule.

### Steps to reproduce:

1. Install the following applications/modules:
   - Attendances
   - Planning
   - Payroll / Work Entries
   - `hr_work_entry_planning_attendance`

2. Create an employee with:
   - Work Entry Source: Planning
   - A flexible working schedule
   - An employee version covering the test date

3. Create two published Planning slots for the same employee on the same day
   and with overlapping times:
   - Slot 1: 08:00–17:00, Allocated Percentage = 100%
   - Slot 2: 08:00–17:00, Allocated Percentage = 99%

4. Create a completed attendance for the same employee on that day, for
   example:
   - Check In: 08:00
   - Check Out: 17:00

5. Save the attendance.

Current behavior:
Attendance creation crashes while recomputing overtime/schedules with a
TypeError caused by mixing `resource.calendar` and
`resource.calendar.attendance` recordsets inside an `Intervals` instance.

Depending on the exact interval boundaries, the error can be:

```
    TypeError: '<' not supported between instances of
    'resource.calendar.attendance' and 'resource.calendar'
```

or:

```
    TypeError: inconsistent models in:
    resource.calendar() | resource.calendar.attendance(...)
```

Expected behavior:
The attendance should be created successfully. Conflicting Planning slots
may still be reported as a Planning conflict, but attendance schedule
recomputation must not crash with an internal TypeError.

### Fix

This commit creates the partial-allocation intervals with an empty `resource.calendar.attendance` recordset instead. This keeps the interval payload model consistent with the working schedule intervals.

opw-6511903

Forward-Port-Of: odoo/enterprise#130820

If a client deletes a standard account or tax, its XMLID can no longer be resolved during the post-init hook. In that case, _load_data() may create a new record using only the provided data, e.g.:

```
('l10n_bg_691001', {'l10n_bg_saft_account_code': '624'})
```

This can lead to incorrect records.

Only update records whose XMLIDs still exist, avoiding the creation of new records when the corresponding standard record has been deleted.

```
File "/home/odoo/src/enterprise/19.0/l10n_bg_saft/__init__.py", line 10, in _add_account_saft_code
    Template._load_data({'account.account': Template._get_bg_saft_account_code()})
  File "/tmp/tmpbu1ntr1j/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 37, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5196, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5103, in _load_records_create
    records = self.create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1055, in create
    )).create(vals_list_for_company)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 329, in create
    threads = super(MailThread, self).create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/tmp/tmpbu1ntr1j/migrations/util/orm.py", line 267, in wrapper
    return f(*args, **kwargs)
  File "/tmp/tmpbu1ntr1j/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
    return super().create(vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/decorators.py", line 369, in create
    return method(self, vals_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4711, in create
    records = self._create(data_list)
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4887, in _create
    cr.execute(SQL(
  File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 440, in execute
    self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_type" of relation "account_account" violates not-null constraint
DETAIL:  Failing row contains (734, null, 1, 1, null, null, null, t, f, f, 2026-08-25 08:18:15.751937, 2026-08-25 08:18:15.751937, no, f, null, null, null, null, 411).
```

upg-4611390
tbg-2902

Forward-Port-Of: odoo/enterprise#129145