… correct remaining value when sbc dropship

**Problem:**
When selling and delivering a subcontracted and dropshipped fifo product, 
the incoming stock valuation layer has a remaining_qty and a remaining_value.
(This also happens with 'standard price' and 'avco' but it's mostly problematic for 
fifo products. This being said the fix solves all 3 cases)

Some context: 
When we confirm a SO and validate the delivery of a dropshipped (not sbc) product,
two svls are created, 
   - one with a negative quantity and value.
   - one with positive quantity and value.
 
Both have a zero remaining value and remaining quantity.
The outgoing svl does not trigger run_fifo or decrease the remaining_qty 
and remaining_value on any svl.
In other words the fifo logic is not applied.
If it was the case, the dropship delivery would impact the fifo valuation and 
other layers which we don't want as the product never really entered the stock.
 
In the use case of this PR, a subcontracted dropshipped fifo product being delivered, 
the outgoing svl(s) are linked to the dropship and have the correct values. 
But the incoming svl is linked to the subcontract order and has a remaining value
and remaining quantity which will impact the fifo logic when it shouldn't.

**Steps to reproduce:**
- enable the subcontracting setting and the dropshipping setting.
- create a storable product, with a fifo category and positive cost.
- create a subonctracted bom with a consumable component.
- in the purchase tab of the product set a vendor which is the same
as the subcontractor of the bom.
- in the inventory tab select only the dropship route
- create and confirm a SO for this product.
- on the PO enter a positive unit price and confirm
- validate the dropship delivery
- click on the valuation smart button

**Current behavior:**
the stock valuation layer linked to the subcontract picking (the one with a 
positive quantity) has a positive remaining quantity and remaining value.

**Expected behavior:**
As the product is dropship remaining quantity and remaining value should be 0

**Cause of the issue:**
When action_done is called on the picking:
1) In the super method,
action_done is called on the move.
There, _create_dropshipped_svl is called.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl
is returned because the location_id (subcontrating location) is valued.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226

2) In the mrp_subcontracting override, button_mark_done is called on 
the mrp.production associated with the picking.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90
Therefore action_done is called on the finished products move the mrp.production.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731
The move is a 'in' move so this lead to the creation of an in svl.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
The problem is that there is no mechanism to prevent the in svl from having 
a remaining_value and remaining_qty

**fix**
The mrp_subcontracting_dropshipping override of _action_done (on stock picking)
is where, when needed, the other ougoing layer is created specifically in this 
subcontracting dropshipping use case.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32
Because the conditions are the same, imo, it's a good place to set the value of 
remaingin_value and remaining_qty of the incoming svl to 0.

opw-5184644

*:website, website_payment

> Commit 1:

[FIX] web_editor: prevent infinite bounce loop when clicking undo
Steps to reproduce:
1. Click on a snippet without dragging it.
2. Notice that the "Drag building blocks here" section starts bouncing.
3. Observe that a step is added to the history (Undo becomes available).
4. Click on Undo button.

Issue:
1. The `o_catch_attention class` is repeatedly added and removed, creating unnecessary history steps in the editor.
2. No actual changes occur in the wrap area, yet the editor records history steps.
3. This leads to an infinite bounce loop when using Undo/Redo.

Expected behavior:
1. The Undo button should not be activated.
2. Infinite bouncing should not occur.

This PR prevents unnecessary history steps by disabling history tracking during this phase using `observerUnactive` and `observerActive`. This ensures that the editor does not record redundant changes, preventing infinite bounce loops.
 
 
 > Commit 2:
 
 [FIX] website_payment: fix donation amount not updating issue
 Steps to Reproduce:
1. Go to Website → Add a Donation snippet.
2. Enter a custom amount and click "Donate". You will be redirected to the donation/pay page.
3. Use the browser's back button to return to the previous page.
4. Change the amount in the custom amount field.
5. Click "Donate" again.
- The old amount is still used instead of the new one.

Expected Behavior:
The donation amount should update correctly when changed.

The issue occurs because clicking the "Donate Now" button appends a hidden value to the form snippet, which is then used in payment_form. When navigating back and selecting "Donate Now" again, a duplicate hidden value is added instead of replacing the previous one. This PR ensures that if a value already exists, it is replaced instead of being
appended, resolving the issue.


> Commit 3:

[FIX] web_editor: fix dropdown options value

Steps to reproduce:
1. Go to the website and drag and drop the form snippet.
2. Change the action to 'Subscribe to Newsletter'.
3. Click on multi-checkbox field to view its options.

- Even after selecting an option, it remains in the dropdown, allowing multiple selections of the same option.

Expected behaviour:
- Once an option is selected, it should be removed from the dropdown.

Solution:
This PR removes the count from the display name, ensuring correct form behavior.

task-4583314

**Description of the issue/feature this PR addresses**:
This pr is to avoid duplicated taxes when the demo data is installed.

**Steps to reproduce**:

1. Install l10n_ar_withholding module with demo data. 
2. Take position in "(AR) Responsable Inscripto" company. 
3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 
4. Delete the filter "Sale or Purchase".
5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"].
6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). 

**Current behavior before PR**:
Duplicated taxes are created when demo data is installed.
<img width="1583" height="784" alt="image" src="https://github.com/user-attachments/assets/49c9f4d4-b599-427b-a786-51191685b3fd" />

**Desired behavior after PR is merged**:
No duplicated taxes are created when demo data is installed.

_Task latam side_: 1360.
_Task Adhoc side_: 57627.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280