fix(frontend): filter relationship selectors by common_parent

[pa-lem]

Summary

Fixes IFC-1646. Relationship selectors in object create/edit forms now honor the common_parent schema property. When a relationship declares common_parent: <X>, its options are filtered to peers that resolve their <X> parent to the same object the user picked for the <X> relationship in the same form — instead of listing every peer (which previously let users pick invalid peers and hit a backend validation error on submit).

Previously the common_parent property was carried into the frontend types but no filtering logic consumed it.

Changes

• useCommonParentFilter hook — watches the sibling <X> field via react-hook-form useWatch, derives the chosen parent id, and returns a single-hop filter in two shapes: a filterQuery ({ <X>__ids: [id] }) for the many/hierarchical inputs and a parent object for RelationshipInput (cardinality one). Uses a sentinel watch name so the hook stays unconditional without subscribing to the whole form.
• Applied across all relationship field types: many, node, generic, and hierarchical.
• On cardinality-one fields, the manual "Parent" filter selector is hidden when common_parent is set, since the parent is then driven by the sibling field (avoids a redundant, potentially contradictory control).

Keeping the selection consistent with the filter (no bypasses)

• Clear on parent change — when the chosen parent changes, the current selection may no longer satisfy the constraint, so it is cleared (a pre-filled value on an edit form is preserved on mount; only a real change clears it).
• "Add new" pre-fills the parent — the inline create form is seeded with the chosen parent (via initialObject → ObjectForm's currentObject) so a peer created there already satisfies the constraint, instead of being an escape hatch. The seed only applies once a parent is selected.
• UUID search — the filter is kept applied on UUID searches (opt-in enforceFilterQueryOnIdSearch), so pasting an out-of-parent UUID no longer bypasses the constraint. Other callers keep the existing UUID-override behavior.
• Hierarchical "Explore" tab — dropped while common_parent applies, because the tree browses the peer's own hierarchy (a different axis) and can't honor the filter.

Testing

• New tests (test-first): a hook test (incl. clear-on-parent-change), a combobox UUID-enforcement test, and per-field wiring tests for many/node/generic/hierarchical (filter applied; manual selector hidden and "Add new" seed passed on cardinality-one; Explore dropped on hierarchical).
• Local gate green: biome, betterer ci, knip, and the form + relationships vitest suites.
• Verified against a reproduction schema in a running instance: with a device chosen, the profile selectors list only profiles under that device, re-filter (and clear a now-invalid selection) when the device changes, and "Add new" opens with the device pre-filled.

🤖 Generated with Claude Code

[cubic-dev-ai]

All reported issues were addressed across 15 files

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>