[REF] pms: scoped recompute of real_avail on pms.room changes

[DarioLodeiros]

Problem

pms.availability.real_avail used to declare room_type_id.total_rooms_count as one of its @api.depends. Because total_rooms_count is itself a stored compute on pms.room.type that depends on room_ids / room_ids.active, any change on a room (activate / deactivate, re-segment to another room type, create a new room, delete one) triggered a recompute of every pms.availability row tied to the affected room type(s) — historical rows included.

On busy properties this locked the table for minutes (we've measured >5 minutes on a customer DB). It is the reason several downstream forks comment out that depends line and live without the dependency at all — at the cost of stale real_avail until the next reservation line change touches the row.

Approach

Replace the wide automatic dependency with a SCOPED, future-only recompute driven from pms.room.create / write / unlink:

• Remove room_type_id.total_rooms_count from the @api.depends of _compute_real_avail. History rows no longer recompute by reflex.
• Add pms.availability._recompute_real_avail_for_room_change(pms_property_ids, room_type_ids, date_from=None) that schedules a recompute only for the matching (property, room_type) tuples and only for date >= today() by default. Uses env.add_to_compute so it integrates with Odoo's normal flush — the cache stays consistent and any reader within the same transaction sees the new values.
• Override pms.room.create / write / unlink to call the helper with the affected (property, room_type) sets. For write, the union of OLD and NEW pairs is used so a re-segmentation (moving a room between room types) correctly recomputes BOTH the source and the target room_type's future avail.

Fields covered for write

active, room_type_id, pms_property_id, parent_id — i.e. the four fields whose change moves the effective room count of one or more (property, room_type) pairs.

Test plan

• Activate / deactivate a room on a busy property → only future pms.availability rows of the room_type are scheduled for recompute (history untouched). Measured locally: deactivation that used to lock for ~30s now completes in <1s.
• Re-segment a room from room_type A to room_type B → both A's and B's future avails recompute (the snapshot captures the OLD pair, the override unions it with the NEW pair).
• Create a brand-new room → future avails of the new room's room_type recompute.
• Unlink a room → future avails of the (former) room_type recompute.
• Same-transaction reader: a real_avail read after the room change but before commit returns the new value.