Why

When a relationship's declared peer is a generic schema, but the cardinality constraint sits on a concrete subtype of that generic (not on the generic itself), the constraint check is silently skipped. The violation only surfaces later, on read, as ValueError: At most, one relationship expected.

Closes #8953 / IFC-2470

Example

Using the schema described in the issue

---
# yaml-language-server: $schema=https://schema.infrahub.app/infrahub/schema/latest.json
version: "1.0"

nodes:
  - name: UnicastIPAddress
    namespace: Network
    inherit_from:
      - BuiltinIPAddress
    relationships:
      - name: layer3
        peer: InterfaceLayer3
        kind: Generic
        optional: true
        cardinality: one
        identifier: ip__l3interface
        direction: inbound

  - name: AnycastIPAddress
    namespace: Network
    inherit_from:
      - BuiltinIPAddress
    relationships:
      - name: layer3
        peer: InterfaceLayer3
        kind: Generic
        optional: true
        cardinality: many
        identifier: ip__l3interface
        direction: inbound

  - name: Layer3
    namespace: Interface
    attributes:
      - name: name
        kind: Text
        unique: true
    relationships:
      - name: ip_addresses
        peer: BuiltinIPAddress
        kind: Attribute
        optional: true
        cardinality: many
        identifier: ip__l3interface
        direction: outbound

Scenario

Create a second Layer3 whose ip_addresses already point at a UnicastIPAddress that has a Layer3 peer -> This is silently accepted. The violation only surfaces later, at read time.

What this PR does

• RelationshipCountConstraint: when the relationship's declared peer is a generic with no matching rel, falls back to resolving each peer's concrete kind and applying that subtype's cardinality / max_count / min_count.
• lock_utils: when the declared peer is a generic, conservatively acquires the lock if any concrete
  subtype carries a count constraint

How to test

INFRAHUB_USE_TEST_CONTAINERS=true uv run pytest \
    backend/tests/component/core/constraint_validators/test_relationship_manager.py \
    backend/tests/component/core/test_get_kinds_lock.py::TestLockGenericPeerConcreteConstraint \
    backend/tests/component/core/test_get_kinds_lock.py::TestLockGenericPeerGenericRel -v

Summary by cubic

Fixes missing count enforcement when a relationship’s peer is generic and the constraint is declared on a concrete subtype. Constraints now run on mutation and locks cover these cases, closing #8953 / IFC-2470.

• Bug Fixes
  • RelationshipCountConstraint: if the generic peer has no matching rel, resolve each changed peer’s concrete kind via NodeGetKindQuery and enforce that subtype’s cardinality/max_count/min_count (respects direction; supports mixed subtypes and generic-vs-concrete declarations).
  • lock_utils: when the declared peer is generic, acquire the count lock if any concrete subtype defines a count constraint for the same identifier (conservative; prevents under-locking).
  • Tests/docs: added tests.helpers.schema.room and expanded matrix for generic peers, max/min, mixed subtypes, and bidirectional cases; use the public relationship getter; removed a redundant same-direction test; clarified the changelog entry.

^{Written for commit 473756f. Summary will update on new commits.}