Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the `blackbox.signCopy` would not be called, causing the test to fail.
2. The `l10n_be_pos_blackbox_urban_piper` tests would crash on `undefined id` on the prep display path of `pos_enterprise`, where the data service will try to load up the prep display data, but it's not loaded in the test bundle. So I created a special setupEnv method for blackbox with urban piper which unpatches the prep display (same mechanism as pos_enterprise)
3. After removing the path for the tests, they would fail for the `expectGeneralProperties` step. By default it expects the `ticketMedium` to be `PAPER`, but there is no printer configured on the tests, so the actual medium is `DIGITAL`.
4. The tests expect the cost center to be `PLATFORM`. There was a patch on `InputGenerator`, which would return platform if the order has a `delivery_provider_id` set. But the patch never fired. I moved the patch directly on the order model, which is where the cost center value is computed.
5. The `test_l10n_be_pos_blackbox_sign_sale_backend_offline` test would endTour prematurely before the orders finished syncing, then check that all the orders are synced. I added an extra isSynced() step to ensure the orders are synced before ending the tour

Task-[6320705](https://www.odoo.com/odoo/1737/tasks/6320705)

## Issue
When a user configures a UPS REST delivery method with **"Require Signature"** enabled, the integration fails during both rating and shipping for US domestic shipments (and certain other origin-destination pairs). 

The UPS API rejects the payload with the following error:
> `The requested accessory option is unavailable between the selected locations.`

## Cause / Root Analysis
There are two distinct issues in the current `ups_request.py` implementation:

**1. Invalid Accessorial Scope (Shipment vs. Package level)**
The current code unconditionally applies the `DeliveryConfirmation` node to `ShipmentServiceOptions`. However, according to the UPS Delivery Confirmation Origin-Destination rules, US domestic, CA domestic, and PR-to-US shipments **must** apply this accessorial at the package level (`PackageServiceOptions`). Applying it at the shipment level causes the UPS API to immediately reject the request.

**2. Invalid DCISType Code**
In both the rating and shipping methods, the code injects `'DCISType': '1'`. According to the UPS REST API schema, `1` does not actually request a signature:
> `1` - Unsupported
> `2` - Delivery Confirmation Signature Required
> `3` - Delivery Confirmation Adult Signature Required

*References to current implementation:*
* [Rating: ups_request.py#L277](https://github.com/odoo/enterprise/blob/6d85b729b96f18df1cb5ecc429b79d3b37671c1f/delivery_ups_rest/models/ups_request.py#L277)
* [Shipping: ups_request.py#L394](https://github.com/odoo/enterprise/blob/6d85b729b96f18df1cb5ecc429b79d3b37671c1f/delivery_ups_rest/models/ups_request.py#L394)

## Expected Behavior & Fix
This PR aligns the Odoo payload with the official UPS REST routing matrix:
1. Changed `DCISType` from `'1'` to `'2'` to correctly request the signature.
2. Introduced a `_get_signature_scope` helper method that evaluates the origin and destination country codes.
3. Dynamically injects `DeliveryConfirmation` into either `PackageServiceOptions` (P) or `ShipmentServiceOptions` (S) based on the exact routing rules specified by UPS.

## Potential Future Enhancements
While this PR resolves the immediate API crash, there are two UX/functional improvements that would better align with real-world shipping workflows:
1. **Move/Mirror Signature Toggle to Order/Transfer Level:** Currently, `ups_require_signature` sits on the `delivery.carrier` method. In practice, shippers rarely use a dedicated shipping method just for signatures; they usually apply a signature requirement dynamically based on order value or contents. Allowing a "Signature Required" boolean directly on the `sale.order` or `stock.picking` would vastly improve usability.
2. **Configurable Signature Type:** This fix defaults to `DCISType: '2'` (Signature Required) to resolve the bug, but exposing a configuration option to select between Standard Signature (`2`) and Adult Signature Required (`3`) would fully round out the integration.

## References (UPS Official Documentation)
* [UPS Shipping API Documentation](https://developer.ups.com/tag/Shipping?loc=en_US)
* [UPS Shipping Appendix (Delivery Confirmation Pairs)](https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US)
* [UPS Rating API Documentation](https://developer.ups.com/tag/Rating?loc=en_US)
* [UPS Rating Appendix (Delivery Confirmation Pairs)](https://developer.ups.com/api/reference/rating/appendix?loc=en_US)