[FIX] ai: scope AI_ADJUST_SEARCH bus event to originating session
The AI_ADJUST_SEARCH handler did not check aiSessionIdentifier, so any
browser tab subscribed to the bus would apply the AI's resulting search
to its current view. When the view's model lacked a field referenced in
the response (e.g. an "Active or Queue" filter on stage_id leaking from
a project.task chat into a timesheet view), the view raised a KeyError.
Align it with the four AI_OPEN_MENU_* handlers, which already drop events
from other sessions since https://github.com/odoo/enterprise/commit/d85e17d9ccf70f9cfd51c7d6b2a5b52510807484.

Steps to reproduce:
- Run Odoo with the crm and contacts modules installed
- Open two tabs:
    - Tab 1: navigate to CRM and ensure you are in List view
    - Tab 2: navigate to Contacts and ensure you are also in List view
- In Tab 1 (CRM), open the Ask AI chat and type "Switch to Kanban view"
- CRM switches to Kanban view as expected
- Bug: Tab 2 (Contacts) also switches to Kanban view along with Tab 1,
  even though you did not interact with it

### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number

While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice

DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check

Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>SETP990001021</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432

### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number

opw-6164321

Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />