…workflow

This commit integrates the Dutch SBR tax reporting process into the `account.return` workflow to provide better visibility, UI feedback, and tracking for users.

Main changes:
* Added a new `l10n_nl_sbr_status` field (Pending, Accepted, Error) to `account.return` to track the submission status for Kanban UI color coding.
* Updated the Kanban view to dynamically apply custom CSS classes (`nl-sbr-error`, `nl-sbr-pending`) to the state bubble based on the SBR status.
* Introduced an `action_refresh_sbr_status` method and a corresponding "Refresh" button in the Kanban view to manually trigger the status check cron.
* Consolidated Chatter messages so that status updates, errors, and submission success notifications log directly on the `account.return` record rather than the closing entry.
* Added an `action_reset_tax_return_common` override to prevent resetting or modifying a tax return once it has been accepted by Digipoort.
* Modified the UI to hide the "Pay" button unless the SBR return has been fully accepted.
* Updated `_on_post_submission_event` to block further processing of the return until the SBR report is accepted.

task-6034675

### Issue:
Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2
https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf

Importing such files raises an error:
`Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.`

### Cause:
The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent
https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698

The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error

### Steps to reproduce:
- Install `l10n_be_coda` and switch to the `BE company`
- Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data)
Before the fix, the error is trigger

opw-6071761

Forward-Port-Of: odoo/enterprise#113904

Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account.

When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied.

On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to
 any journal item.

To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines.

opw-6107329

Forward-Port-Of: odoo/enterprise#114863

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/enterprise#114786

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359

Forward-Port-Of: odoo/enterprise#114942
Forward-Port-Of: odoo/enterprise#110652

When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448