Versions
--------
18.0+

Issue
-----
The `test_website_sale_add_and_remove_main_product_image_no_variant` and `test_website_sale_remove_main_product_image_with_variant` tours fail because the main product image is not removed as expected after the tour completes.

Cause
-----
Both tours assume that once the product `<img>` element is removed from the DOM, the action is fully completed. The tour then ends, and the remaining Python code verifies the result. However, this assumption can lead to issues. If the save request takes longer than expected, the Python code may execute prematurely and fail.

Solution
--------
Add a step at the end of both tours to wait for the `<img>` element to be fully saved and updated in the preview DOM.

Additionally, during debugging, it was observed that using an alias URL (i.e., a redirect) to an `ir.attachment` could introduce further issues or slow down the test due to the server fetching the image with a remote call. To address this, this commit replaces the alias URL with a simple binary attachment.

opw-5159593
runbot-163025
runbot-163615

**PROBLEM**
Internal users can access the documents of a private project even when they are not followers of the project. They shouldn't.

**STEP TO REPRODUCE**
1. Create a project, and set its visibility to Invited internal users (private), and upload a document to the project folder.
2. Switch to a user that is not a follower of the project, but is a user of the document app.
3. Go to the documents app, and notice you have access to files in the private project folder.

**CAUSE**
1. When creating the project folder, we don't specify `access_ids`, which means it will copy the `access_ids` of the folder above it. If a user have access to the "Project" folder, they will have access to any sub-folder ("Project" folder is the default parent folder of the any project folder).
2. `is_access_via_link_hidden` is by default set to False, which means the project folder is visible to anyone who has access to its parent folder.

**FIX**
1. Don't copy `access_ids` from the parent folder.
2. If project visibility is private, `is_access_via_link_hidden` is set to True.
3. To give access to the folder to the followers of the project, update the `access_ids` of the project folder and documents when add/removing followers.

opw-4791346

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

Issue
-----
Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML.

Steps to reproduce
-----
- Create a subcontracted product with 2 components
- Add one of each component in subcontractor's stock
- Create a PO for the finished product and confirm it
- Go to the production
- Open the "Record components" wizard
- Set quantity then remove the second line
- Confirm production (don't update consumption)
- Go to Inventory > Reporting > Moves History and remove the "Done" filter

> There is a pending move in the report

Cause
-----
When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method

https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46

The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do

`move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])`

we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db.

https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322

We cannot change the field to `ondelete='cascade'` as such a change would not be stable.

Solution
-----
Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated.

-----
Ticket:
opw-4817397

Forward-Port-Of: odoo/odoo#229310