Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.

It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].

This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).

Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
    def _load_records_write(self, values):
        values.pop('active', None)
        super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804

task-2963840

(Follow-up of https://github.com/odoo/upgrade/pull/3829)

Forward-Port-Of: odoo/odoo#233899
Forward-Port-Of: odoo/odoo#104836

**Description of the issue/feature this PR addresses**:
This pr is to avoid duplicated taxes when the demo data is installed.

**Steps to reproduce**:
1. Install l10n_ar_withholding module with demo data.
2. Take position in "(AR) Responsable Inscripto" company.
3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes".
4. Delete the filter "Sale or Purchase".
5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"].
6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy).

**Current behavior before PR**:
Duplicated taxes are created when demo data is installed.
<img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" />

**Desired behavior after PR is merged**:
No duplicated taxes are created when demo data is installed.

_Task latam side_: 1360.
_Task Adhoc side_: 57627.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#226992

The system will crash when user tries to uninstall the `invoicing` module.

**Steps to produce:**
- Install `Accounting` module without demo data.
- Go to Accounting > Configuration > Settings > Set fiscal localization as
  `United States`.
- Go to `Apps > Accounting > uninstall`.
- Now try to uninstall `Invoicing` module.

**Error:**
`KeyError: 'account.asset'`

**Cause:**
- [Here] in `l10n_us_account` module, we define data of `account.asset` model.
- When we uninstall the `accountant` module, it also uninstalls `account_asset` module and also uninstall the `account.asset` model.
- the asset data loaded by `l10n_us_account` was incorrectly owned by the `account` module.
- When we later uninstall the `account` module, it finds `account.asset` data and tries to delete it.

**Solution:**
- Added uninstall_hook in l10n_us_account to unlink the account.asset record.

[Here]https://github.com/odoo/odoo/blob/e1dd3852b118eacc8d77e9e3d8c7769195c6edb1/addons/l10n_us_account/data/template/account.asset-us.csv#L2-L8

**sentry-6938852090**

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.

It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].

This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).

Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
    def _load_records_write(self, values):
        values.pop('active', None)
        super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804

task-2963840

(Follow-up of https://github.com/odoo/upgrade/pull/3829)

Forward-Port-Of: odoo/odoo#233899
Forward-Port-Of: odoo/odoo#104836

**Steps to reproduce:**
1. Go to Products > Create a new product.
2. Add or create a new attribute and set a long text value.
3. Go to Sales > Open any quotation.
4. In the sale order line, click on "Catalog" and search for the created product.

**Issue:**
- The attribute value text overflows outside the product card in the kanban view, causing layout misalignment and making the UI look broken.
<img width="509" height="157" alt="image" src="https://github.com/user-attachments/assets/a2af2c6d-9265-451c-9d1e-526df8487841" />

**Cause:**
- The inner `<div>` containing the attribute text did not have a width constraint, causing it to exceed the container width when the text length was large.

**Solution:**
Added the Bootstrap class `w-100` to the <div> element to ensure the content fits within the parent container and wraps properly inside the card.
<img width="322" height="166" alt="image" src="https://github.com/user-attachments/assets/5ba82207-7f52-4f9e-b400-e4ab4e79f0a0" />


**opw-5222002**

**Issue**
When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch.
Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view

**Steps to Reproduce**
1. Create and confirm a subscription with a recurring product (e.g., Car Leasing)
2. Generate and post the invoice for the subscription
3. Add a new product line to the subscription (e.g., Office Cleaning Service)
4. Delete the original invoiced line (Car Leasing)
5. Attempt to create an invoice for the new product line
→ Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category."
(https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view)

**Root Cause**
Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation.

**Fix**
Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation.