fix(recompute): refresh a reader's derived values when its read peer is deleted

[gmazoyer]

Why

Deleting a node that other nodes read across a relationship left the readers with derived values (display label, human-friendly id, computed attribute) that still named the deleted peer after a merge or rebase. Tracked in IFC-2852.

Root cause

The reader does appear in the merge/rebase change set, but as an update whose changed field is the relationship to the deleted peer. The coalesced deriver treated updates as needing no self recompute, on the assumption the node refreshed its own derived values inline on the save that recorded the change. A peer deletion never triggers that inline recompute (the reader is not saved, its edge is closed from the peer side). The only submission was a reverse lookup from the deleted peer, which finds no readers once its edges are closed, so the reader kept its stale value.

Fix

An update whose changed fields include a relationship now also recomputes the node's own derived values that read across it, keyed by the node's own id. This works because the reader still exists. It covers both merge and rebase through the shared build_coalesced_recompute. Attribute-only updates are unchanged, so the coalescing behavior for the common case is preserved.

Tests

• Un-marked and broadened the former strict xfail test_deleting_read_peer_refreshes_reader_after_merge to assert the computed attribute and display label stop naming the deleted peer and the human-friendly id (local name only) is unchanged, using the full cross-relationship display label.
• Added test_merge_submits_delete_peer.py: a component test asserting the reader is recomputed by its own id for the computed attribute and display label.
• Full coalescing component suite green locally (17 passed). Local integration_docker was blocked by a slow-boot healthcheck timeout on the dev machine (the server boots cleanly, just slower than the stack wait window), so the end-to-end integration test is verified here in CI.

Notes

• Stacked on coalesce-merge-recompute-ifc-2761 (Coalesce merge and rebase recompute #9751); will retarget to develop if that merges first.
• The live delete path (outside the coalesced deriver) is a separate concern noted in IFC-2852.

---

Summary by cubic

Refreshes a reader’s computed attribute, display label, and HFID when its relationship changes during merge/rebase—including when the peer is deleted—so values stop naming the deleted node (IFC-2852). Adds a safe fallback for unscoped updates that also recomputes the node’s own derived values.

• Bug Fixes
  • UPDATED with relationship fields also recomputes the reader’s own derived values, keyed by its id; attribute-only updates unchanged.
  • Unscoped UPDATED imprecisely recomputes cross-node readers and the node’s own derived values.
  • Coalesces affected readers into one submission per family; component test asserts own-id coalescing and integration verifies summary refresh with HFID unchanged.

^{Written for commit 694204d. Summary will update on new commits.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing recompute-deleted-peer-readers-ifc-2852 (694204d) with develop (049b821)}

[cubic-dev-ai]

1 issue found and verified against the latest diff

Confidence score: 3/5

• In backend/infrahub/core/merge/recompute_coalescing.py, unscoped UPDATED changes can skip the reader-by-own-id recompute when the unrecorded change is relationship-only, because _changed_relationship_fields() may return None when changed_fields is empty; merging as-is risks stale or incorrect read results after merges. Ensure relationship-only updates are treated as relationship changes (instead of None) and add a regression test for the unscoped UPDATED path before merging.

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

Re-trigger cubic</sub>