**Problem:**
In the "Schedule Activity" dialog and other views using the `selection_badge_icons` widget for many2one fields, every activity type badge renders the same check icon instead of its configured icon (envelope, phone, users, upload, warning, ...).

**Steps to reproduce:**
1. Open any record with a chatter (e.g. a Contact)
2. Click "Schedule Activity"
3. Observe the activity type selector **Current behavior:**
Every activity type shows `fa-check`.
**Expected behavior:**
Each activity type shows its configured icon from
`mail.activity.type.icon` (e.g. `fa-envelope` for Email, `fa-phone` for Call, ...).

**Cause of the issue:**
The many2one loader in `BadgeSelectionWithIconsField` (`selection_badge_icons`) was recently extended to support an optional icon mapping so a related-field value that is itself a selection key can be translated into an icon class (used e.g. by the homework location wizard: `home` -> `fa-home`). However, `iconMapping` defaults to `{}` via `defaultProps`, and the new branch was written as:
https://github.com/odoo/odoo/blob/7714b55eb9386d3cedd79d3ce4de7475b09af69a/addons/mail/static/src/views/fields/badge_selection_icons/badge_selection_icons_field.js#L52-L56

The empty default `{}` is truthy, so the code always takes the mapping branch. When no `icon_mapping` is configured in XML — the common case, since `mail.activity.type.icon` already stores raw Font Awesome classes like `fa-envelope` — the lookup `{}["fa-envelope"]` returns `undefined` and the final `|| defaultIcon` collapses every option to `fa-check`. This affects the activity schedule wizard, the activity form view, and the activity-related server action view.

**Fix:**
Looking up the mapping with optional chaining and falling back to `relatedFieldValue` keeps `icon_mapping` purely additive: when it is provided and contains the value, the mapped icon wins; when it is absent or does not contain the key, the related field value is used directly as the icon class. This preserves the selection-key mapping use case (homework location wizard) while restoring the raw-icon use case (activity types, server actions).

opw-6123405

**Steps to reproduce:**
* Install `l10n_mx` module.
* Go to Accounting > Assets and create a new asset.
* Attempt to select a Fixed Asset account in the corresponding field.

**Observed behavior:**
* No existing Fixed Asset accounts correctly show up in the selection.
* Even if an asset goes through by force-creating an account, the automatic depreciation flow fails because the depreciation models generate a single yearly entry instead of monthly, and the depreciation/expense accounts have incorrect account types.

**Cause:**
* The chart of accounts had Accumulated Depreciation template accounts (e.g., `171.05.01`) set to `expense_depreciation` instead of `asset_non_current`, rendering them unavailable for the Accumulated Depreciation field.
* The Depreciation Expense accounts (e.g., `613.05.01`) were conversely set as `expense_direct_cost` instead of `expense_depreciation`.
* The main Fixed Asset accounts (e.g., `156.01.01`) were completely missing the explicit mappings for `asset_depreciation_account_id` and `asset_expense_account_id` within the CSV definition.
* The depreciation models in `account.depreciation.model-mx.csv` were configured with a `method_period` of `12`, resulting in yearly rather than standard monthly entries.

**Fix:**
* Modify `account.account-mx.csv` to convert all `171.xx/183.xx` accounts to `asset_non_current` and all `613.xx/614.xx` accounts to `expense_depreciation`.
* Introduce the `asset_depreciation_account_id` and `asset_expense_account_id` columns into the `account.account-mx.csv` file, properly linking each Fixed Asset account to its correct depreciation targets.
* Update `account.depreciation.model-mx.csv` to use a `method_period` of `1` (monthly) and convert the `method_number` logic from yearly durations to full month durations (12, 36, 60, and 120 months respectively) for creating accurately timed entries.

opw-6091214

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount.

This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`.

This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time.

[1]: odoo#169264
[2]: odoo#154349

Forward-Port-Of: odoo/odoo#263860