Prior to this commit, creating a multi-action that moved a document to a
new folder and immediately triggered another action (e.g., "Create
Invoice") often failed. This occurred because the security check required
the sub-action to be explicitly embedded (pinned) on the *destination*
folder. Since the record was moved during the process, the subsequent
action failed the security check on the new folder where it wasn't pinned.

This limitation caused confusion for users setting up automation flows,
as the intent of the sequence (Move -> Action) was clear and initiated
from a valid context (the source folder), but strict per-action security
rules blocked execution.

This commit improves the `ir.actions.server` execution logic to support
this pattern by introducing a context-based security sentinel:

1. Entry Point Validation: When a Documents action (root) is triggered,
   the system enforces strict security: the action must be explicitly
   embedded on the record's current folder.
2. Context Inheritance: Once the root action is authorized and begins
   execution, it sets a secure sentinel in the context.
3. Trusted Execution: Any subsequent sub-actions (children) detect this
   sentinel and are allowed to run, regardless of the record's current
   folder location.

This ensures that if a user has the right to start the process (the root
action), they have the right to complete the defined sequence, even if
intermediate steps move the record to a folder where the sub-actions are
not explicitly pinned.

As a result, the `_can_execute_action_on_records` override in
`documents_account` is no longer necessary and has been removed.

Tests have been extended in the `documents` and `documents_account` 
modules to cover these scenarios (using Tags in the `documents`
module instead of Accounting-specific models to make the tests generic).
A new test file `test_documents_ir_actions_server.py` was created
to maintain a clean testing environment, covering nesting, move sequences,
and RPC spoofing attempts.

Task-5916630

Forward-Port-Of: odoo/enterprise#106702

**Steps to reproduce:**
* Install `Accounting` and `accounting_peppol` modules.
* Create Belgium company.
* Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`.
* Create and post a customer invoice.
* Click **Send & Print**.
* Select only **Email** and click **Send** to generate the PDF.
* Click **Send & Print** again.
* Select only **Peppol** (partner configured for Peppol).
* Click **Send**.

**Observed behavior:**
* The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF.
* The receiver gets the XML data without the PDF representation.

**Cause:**
* When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it.
* The PDF embedding into the UBL XML relies on this post-processing step.
* Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic.

**Fix:**
* When sending via **Peppol**, detect if a PDF already exists on the invoice.
* If so, explicitly post-process the UBL XML to embed the existing PDF before sending.
* Ensures the PDF is always included in Peppol messages, regardless of when it was generated.

opw-5495465

Forward-Port-Of: odoo/odoo#245901

When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account.

Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient.

The `partner_bank_id` can be assigned through different processes:

- If the wizard has only one batch:

The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`.

- If there are multiple batches:

Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id'].

The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly.

I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are.

-Previous PR : [242863](https://github.com/odoo/odoo/pull/242863)

However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here.

Ticket: opw-5401372

Forward-Port-Of: odoo/odoo#249537
Forward-Port-Of: odoo/odoo#246558