* = account_reports,l10n_{in_asset,ph_reports_asset,ro_saft}

This commit enables a single asset to carry multiple depreciation
configurations (variants), each targeting a different ledger. This allows
the same asset to be depreciated under multiple accounting regimes (e.g.,
statutory vs. book) simultaneously.

Changes:

- Introduces `account.asset.variant` model: moves most depreciation
lifecycle logic (board computation, disposal, sale, modification)
from `account.asset` onto variants. A single asset owns multiple
variants, each with its own model, journal, accounts, and state.

- Renames `account.move.asset_id` to `asset_variant_id`: all depreciation
moves now link to a variant instead of an asset directly. Downstream
integrations (fleet, l10n_*, reports) are updated accordingly.

- Adds ledger account fields to `account.depreciation.model`
(`ledger_depreciation_account_id`, `ledger_expense_account_id`,
`ledger_recovery_account_id`) so a depreciation model used for a
ledger variant carries its own account mapping.

- Adds `ledger_depreciation_model_ids` on `account.account` so default
ledger depreciation models can be configured per account, enabling
automatic multi-variant asset creation from bills.

- Adds UI: asset variant list view, depreciation ledger list/form
views, ledger-specific sections on the depreciation model form,
conditional button visibility based on variant state, and a wizard
(`depreciation.ledger.wizard`) to attach a ledger-based depreciation
model to an existing asset.

- Adapts the account asset report SQL to operate at variant level:
restructures CTEs to group values by variant, avoids double-counting
asset cost values across variants, and adjusts disposal/recovery
logic for the multi-variant scenario.

- Updates `l10n_ro_saft` SA-FT asset queries and `l10n_in_asset`
computation overrides to work with `account.asset.variant`.

- Adapts existing tests and adds test file (`test_asset_ledger.py`)
covering ledger variant creation, board generation, disposal, and
report output.

task-5961309

Rework the mobility budget logic according to Partena requirements.

* Settle the remaining mobility budget in December or on the employee's
  final monthly payslip instead of in the anniversary month.
* Support Pillar 2 payments through payslip inputs even when the Expenses
  module is not installed.
* Add dedicated salary rules for mobility budget amounts already paid,
  remaining balances, and Pillar 3 payments, including payments related
  to the previous year.
* Include the mobility budget amount in termination fee computations.
* Compute the yearly mobility budget as a prorated amount based on all
  employee versions within the calendar year, where required for payroll
  calculations and the 281.10 declaration.
* Adapt the DMFA mobility budget declaration to report the applicable
  yearly mobility budget for Pillar 3 payments, including payments related
  to the previous year.
* Add warnings when Pillar 2 or Pillar 3 payments are inconsistent with
  the remaining mobility budget.
* Add warnings when the mobility budget falls outside the configured
  boundaries or exceeds 20% of the yearly wage.
* Add a dashboard warning for employees with a mobility budget and a
  company car emitting CO₂.
* Move the computation of the default mobility budget amount from
  l10n_be_hr_contract_salary to l10n_be_hr_payroll, so that the mobility
  budget amount is available without requiring the salary configurator
  module to be installed.

Related upgrade PR:https://github.com/odoo/upgrade/pull/11241

Task: 6263962

This PR applies several changes to revamp the export data dialog.

First commit modernizes the layout and behavior of the export dialog:

Layout:
- Replace the "I want to update data (import-compatible export)" checkbox with a more compact "Updatable fields only" switch, placed next to the "Available fields" title it actually filters.
- Replace the export format radio buttons with a select displayed below the available fields, freeing vertical space in the right panel, and name the formats "Excel Workbook (.xlsx)" and "Plain Text (.csv)" instead of bare extensions.
- Add a search icon inside the search input, hidden as soon as the user starts typing.
- Use caret icons and the standard emphasis hover color in the fields tree instead of the brand color overlay, and drop the special styling of expanded items.

Behavior:
- Toggling "Updatable fields only" now only refreshes the available fields and keeps the export list untouched, instead of resetting it to the default/template list.
- Hide the "add" icon of fields already selected instead of rendering it in a disabled state.
- Ignore the trash icon in the draggable hook so removing a field cannot accidentally start a drag sequence, and give it a pointer cursor.

Second commit adds translation support to export: since https://github.com/odoo/odoo/pull/224997, the import supports
translated fields through the `field@lang` header convention (e.g. `name@fr_FR`). The commit adds the counterpart on the export side.

Server:
- `_export_rows()` now accepts field paths suffixed with `@` and a language code and exports the translation of the field in that language, mirroring the import convention (including nested paths such as `line_ids/name@fr_FR`).
- `/web/export/get_fields` and `ir.exports._get_fields_info()` expose a `translate` flag so the client knows which fields are translatable.

Export dialog:
- Add a "Languages" input at the bottom of the "Fields to export" column, only shown when more than one language is installed. The selected languages are displayed as removable tags next to an inline autocomplete listing the remaining installed languages.
- On export, each translatable field of the export list is replaced by one column per selected language, using the `field@code` syntax. An import-compatible export can thus be re-imported with its translations directly.
- Languages export preferences can also be saved and loaded into/from export templates.

Layout:
- Rework the two-pane layout into a 2-column CSS grid so each horizontal pair (titles, search/template, field lists,
format/languages) shares a row and stays vertically aligned with equal heights - in particular the Format select and the Languages input.

Third commit improves export template creation/edition UX.
Templates can now be renamed and have their fields/order/languages changed in-place, instead of only supporting a separate "New template" option. Changing the export list, field order or languages while a template is selected but not being edited detaches from it, keeping the current selection as an unsaved working set instead of forcing edition mode, so a new template can be built on top of an existing one without altering it.

ir.exports.line gains a sequence field so the field order of a template is preserved across saves.

task-6090205