Currently, for products with variants, the quantities on hand displayed in the product configurator can be incorrect.

### Steps to reproduce

* Install `point_of_sale`.
* Start the furniture shop POS session.
* Click on the Conference Chair; the steel legs are selected by default, and the system displays quantities on hand as 30.
* Switch to aluminum legs; the quantity remains 30.
* Switch back to steel legs.

You should see that the quantity on hand is now 26. This is the actual, correct quantity for steel legs. The originally displayed value of 30 was already incorrect for those legs.

### Cause

The issue arises from how the product's quantities on hand are fetched and updated:

- The `useEffect` hook is used to fetch quantities on hand whenever the product changes.
- However, the function used to retrieve these quantities (`fetchStock`) is wrapped with `useTrackedAsync`, which internally utilizes `useAsyncLockedMethod`.
- The `useAsyncLockedMethod` hook ensures that two calls to `fetchStock` cannot run simultaneously; if `fetchStock` is called while another call is still in progress, the subsequent call is ignored.

This behavior causes the problem. In the product attribute component, the `useEffect` hook is triggered twice in rapid succession when switching attributes. Since the second `fetchStock` call happens before the first completes, it is discarded due to the locking mechanism. As a result, the product changes twice, but the stock fetching process is executed only once, causing a mismatch between the selected product variant and its displayed quantities on hand.

### Fix

The `useTrackedAsync` utility was updated to allow specifying the locking mechanism. Specifically, it now supports an option to keep the last call instead of the first. This change ensures that even when multiple `fetchStock` calls are triggered in quick succession, the most recent call is executed, maintaining synchronization between the product variant and the displayed stock quantities.

opw-4421070

Before this commit, the form compiler did a search in the whole DOM, when compiling a form, to find anchors, for which the target node would be in the form being compiled. The point of this was to automatically open the notebook tab when an anchor is click for an element that is hidden in a non active tab.

However, looking in the DOM makes no sense. It's very likely that the found element won't be there anymore when the view we compile will be put in the DOM, and moreover the compilation is done only once, so if we come back later on on the same form, we'll still use the information of the anchor we found the first time, which is ever less likely to be again in the DOM.

This was actually a code mistake, as what we aimed to do was to find anchors **in the form**, pointing to elements hidden in the notebook, but definitely not **in the dom**.

This mistake produces a crash: go to "Timesheet / Configuration / Settings" and try to open the "Internal" project in the time off section => traceback.

This commit removes the look up in the document. The feature of automatically opening the tab already partially works, but we won't fix it, and we'll even drop it in master.

opw~4457605

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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