Steps to reproduce
1. Add a one2many field on product.product targeting purchase.order.line with relation_field product_id (e.g. through Studio).
2. Set its domain to [('state', 'in', ('purchase', 'done'))].
3. Ensure the "Purchase Order Line multi-company" rule (purchase.purchase_order_line_comp_rule) is active.
4. Create a new RFQ with one product line and save.

Issue
Saving the RFQ raises an AccessError. When product_id is assigned on the new line, Many2one._update_inverses walks every inverse one2many of product_id and calls records.filtered_domain(invf.get_domain_list(...)) to know which lines belong in the inverse cache (see https://github.com/odoo/odoo/blob/ee82034be1fa720577508ffbc7be41a198be7588/odoo/fields.py#L3215). For the Studio-added one2many, the domain references `state`, a stored related field on purchase.order.line. Resolving it through filtered_domain (https://github.com/odoo/odoo/blob/ee82034be1fa720577508ffbc7be41a198be7588/odoo/models.py#L6257) ends up consulting ir.rule on purchase.order.line, and the multi-company rule rejects the read in this transient state, which aborts the save.

Native one2many fields don't carry this kind of stored-field domain on the inverse side, so the issue only surfaces once such a field is declared (typically via Studio).

Solution
Run the inverse-cache domain filter in sudo. _update_inverses only updates the in-memory cache of the inverse one2many; it is not a security boundary and the records being filtered are the ones the user is currently writing, so they already have access. Sudo'ing the predicate evaluation lets the bookkeeping run without being blocked by record rules on the comodel side.

opw-6057361