Please address the comments from this code review:

## Overall Comments
- There are unresolved merge conflict markers in central/complianceoperator/v2/compliancemanager/manager_impl.go (<<<<<<< HEAD / ======= / >>>>>>> …) that need to be resolved before merging.
- The tailored-profile equivalence logic is now implemented in both the datastore (resolveEligibleProfileNames/hash checks) and the manager (validateTailoredProfileHashConsistency), which risks future drift; consider centralizing this hash-consistency logic in a shared helper to keep behavior aligned.

## Individual Comments

### Comment 1
<location path="central/complianceoperator/v2/compliancemanager/manager_impl.go" line_range="582-591" />
<code_context>
+<<<<<<< HEAD
</code_context>
<issue_to_address>
**issue (bug_risk):** Unresolved merge conflict markers must be resolved before merge

In this file, there are still `<<<<<<<`, `=======`, and `>>>>>>>` markers around the tailored profile validation logic. Select the correct version of the code, remove the markers, and ensure the file compiles before merging.
</issue_to_address>

### Comment 2
<location path="sensor/kubernetes/complianceoperator/dispatchers/complianceoperatortailoredprofiles.go" line_range="132-138" />
<code_context>
 			OperatorKind: central.ComplianceOperatorProfileV2_TAILORED_PROFILE,
 		}

+		var ruleNames []string
 		for _, rule := range protoProfile.GetRules() {
 			protoProfileV2.Rules = append(protoProfileV2.Rules, &central.ComplianceOperatorProfileV2_Rule{RuleName: rule.GetName()})
+			ruleNames = append(ruleNames, rule.GetName())
 		}

+		protoProfileV2.EquivalenceHash = computeProfileEquivalenceHash(
+			tailoredProfile.GetName(),
+			tailoredProfile.GetNamespace(),
</code_context>
<issue_to_address>
**question (bug_risk):** Equivalence hash ignores some potentially relevant fields (e.g., values)

The hash currently covers only name, namespace, description, title, and rule names. If other fields (such as values/variables that influence rule evaluation) affect profile behavior, differences in those fields will be ignored. If tailored profile values are behaviorally significant, they should also be included in the hash so non-equivalent tailored profiles aren’t treated as equivalent across clusters.
</issue_to_address>