When creating a write-off for multiple multicurrency journal items that where created with the same rate, the reconciliation wizard will recompute the balance of the write-off based on the residual amount of the journal items in invoice currency and the reconciliation rate.

Because each journal item applied rounding separately, the resulting amount might differ from the residual amount of the journal items in company currency, which will trigger the creation of an exchange difference entry (for a few cents).

This entry is spurious and confusing for the user because the reconciled journal items all shared the same currency and rate and therefore the reconciliation does not correspond to a currency exchange event.

After this commit, when computing the residual amount to write-off in the reconciliation wizard, we check whether the journal items used the same rate as the reconciliation rate, and in that case we directly take the residual amount of the journal item in company currency instead of recomputing the residual amount based on the invoice currency amount and the reconciliation rate, thus avoiding rounding errors.

task-4247344

Currently, a traceback occurs if the user installs an inventory module, 
When the accounting module was installed, there was no state_id in the company.

To reproduce this issue:

1) Install `Accounting` and remove the state from the company
2) Update a Fiscal Position record with Foreign Tax and Federal State
3) Now install the inventory module

Error:-
```
TypeError: sequence item 0: expected str instance, bool found
```

Here, State_id is not a required field in the company, So, the user can remove it.
When there is no `state_id` and a fiscal position record has a Foreign Tax.
We get a traceback from the below lines.

https://github.com/odoo/enterprise/blob/1c6f0273e76b6dfb89ef65eb359e620b9c4c5759/account_reports/models/res_company.py#L216-L219

This is because we have a `vat_fpos_with_state_count` value due to foreign vat in fiscal position, 
but we don't have a state_id in the company.

So the `state_codes` value will be a list of bool, which leads to the above traceback.

We can resolve this issue by making the code more robust.

sentry-6203209197

When a tag has both a very long category and a very long tag name, the delete icon becomes misaligned due to text overflow. This causes the clickable area for the icon to shift away from where the icon is visually displayed. As a result, users might think they cannot delete the tag because clicking directly on the icon does not trigger the delete action.

To fix this, we can apply `max-width: 2ch` to the delete icon. Since the icon will always be one character's width, giving them 2ch width will be enough to properly display it without taking more space than needed, and ensures that the icon remains properly aligned with the tag, regardless of text length.

This ch unit corresponds to be Equal to the “0” (ZERO, U+0030) glyph found in the font used to render it.

Before the fix:
<img width="296" alt="image" src="https://github.com/user-attachments/assets/f3f45666-0c21-4334-823a-a2afacd5ebe2" />

After the fix:
<img width="292" alt="image" src="https://github.com/user-attachments/assets/7deb8253-bcd3-4469-9c5b-8a135591d331" />


FW-bot up to 18.0

opw-4403905