IFC-2113: Fix failure when removing a profile with a many relationship and overriding with same peers

[solababs]

Why

When a node's cardinality-many relationship is sourced from a profile (peers A, B, C) and the user saves an override containing a peer that also appears in the profile (e.g. [C, D, E]), peer C is silently dropped. Only D and E remain.

The root cause: RelationshipManager.update() reuses the existing Relationship object for C without clearing its is_from_profile=True flag. When NodeProfilesApplier.apply_profiles() runs immediately after (before save()), it sees C as profile-sourced and removes it because C is not in the set of user-set peers.

This PR clears is_from_profile and the source metadata on any reused relationship peer when the user explicitly includes it in their override.

What changed

• RelationshipManager.update() now clears is_from_profile on reused peers — when a peer from previous_relationships is included in the new override list, is_from_profile is set to False and clear_source() is called before appending to _relationships. This applies to all three reuse branches (node-object, string peer-ID, dict).

• After the fix, when apply_profiles() runs, the overlapping peer is already in user_set_peer_ids and is not removed. No schema changes, no API changes, no change to NodeProfilesApplier logic.

How to test

uv run pytest backend/tests/component/core/profiles/ -v
# 49 passed (was 47 passed + 2 xfailed)

The previously-xfailed test_get_many_with_profile_relationships_partial_override now passes and validates the fix directly: profile sets things=[T0, T1], user calls things.update([T1, T2]), result is exactly [T1, T2] with no profile source.

Impact & rollout

• Backward compatibility: The fix only affects the case where a user override includes a peer that was previously profile-sourced. Peers that are in the profile but absent from the override are still removed (existing behavior preserved). Safe to deploy.

Checklist

• Tests added/updated
• Changelog entry added (uv run towncrier create ...)
• External docs updated (if user-facing or ops-facing change)
• Internal .md docs updated (internal knowledge and AI code tools knowledge)
• I have reviewed AI generated content

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Shadow auto-approve: would auto-approve. The change is a narrowly scoped bug fix that clears the is_from_profile flag on reused relationship peers to prevent them from being incorrectly removed by the profile applier, with a small line count, passing tests, and no impact on API, schema, or infrastructure.

Re-trigger cubic</sub>

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing fix-profile-many-rel-override-ifc-2113 (5c42f3e) with stable (edaeba7)¹}

Footnotes

1. No successful run was found on stable (ce9356b) during the generation of this report, so edaeba7 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[ajtmccarty]

should either add this to the exceptions in pyproject.toml or refactor the method so the error isn't raised

[ajtmccarty]

not caused by this PR, but it looks like this function does not correctly validate the case where peers are defined and source_uuid="", which is what we need to test for this case. it looks like it correctly tests that the source of the peer(s) is empty if no ExpectedProfileRelationship for the relationship name, but does not verify that if the ExpectedProfileRealtionship is defined with a source set to the empty string