Description of the issue/feature this PR addresses:

Race condition in _update_available_quantity causes serial-tracked products to end up with reserved_quantity > quantity on a quant, leading to delivery validation hanging with a timeout.

The method uses FOR NO KEY UPDATE SKIP LOCKED to avoid deadlocks when updating quants. When two concurrent transactions both try to reserve the same serial number and the first one holds the lock, the second transaction falls through the SKIP LOCKED path and creates a duplicate quant with quantity=0, reserved_quantity=1 instead of waiting. After _merge_quants consolidates the duplicates, the summed reserved_quantity=2 exceeds quantity=1. _clean_reservations then perpetuates this state because it syncs quant reservations to match the sum of active move lines, which also totals 2.

Current behavior before PR:

When two transactions concurrently reserve the same serial number, the quant ends up with reserved_quantity=2, quantity=1. This makes available_quantity = -1. On the next delivery validation for that serial, _free_reservation is triggered and, depending on the location's removal strategy, the A* package search algorithm enters an unresolvable loop and times out, blocking the delivery indefinitely.

Desired behavior after PR is merged:
                                                                                                                    For serial-tracked products, reserved_quantity at the moment of writing (in_update_available_quantity). Concurrent reservation attempts on a fully-reserved serial silently no-op instead of creating an over-reservation. _clean_reservations also respects this invariant when syncing quant reservations from move lines. Pre-existing corrupted quants (auantity > quantity) are corrected on the nextscheduled cron execution.

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