A report-side Unresolved reason suffix still splits the fingerprint from its DMV twin

[erikdarlingdata]

Found while implementing [#1893], and deliberately left out of that PR.

[#1893] closed the last database-naming gap between the two blocking collectors: both now write Unresolved: <type> lock, database: <resource database> for a lock whose object they could not name, so a cross-database lock fingerprints once. One difference remains, and it is not about the database.

[#1865] gave the report side's sentinel a trailing reason — Unresolved: key lock, database: Foo (no metadata access), (page reallocated), (database unavailable), (page lookup needs sql server 2019). The DMV side has no equivalent and cannot acquire one: it never attempts the object lookup, so there is no failure to classify. So when both collectors see the same unresolvable lock AND the report side attached a reason, the labels differ by that suffix:

	label
blocked_process_report	Unresolved: key lock, database: Foo (no metadata access)
dmv_blocking_snapshots	Unresolved: key lock, database: Foo

[#1876]'s normalizer deliberately preserves the suffix (pinned by A_Label_Already_In_Report_Form_Is_Returned_Untouched, which includes a (page reallocated) case), so these hash to two DedupKeys — a third-order version of the same defect [#1876] and [#1893] each narrowed.

Why it is narrow

It needs the report side to have attached a reason at all, which happens in two situations:

• (no metadata access) — the monitoring login has no user in the contended database. Permanent while the posture lasts, so the split is stable rather than churning: one extra incident, not a stream of them.
• (page reallocated) — transient by definition, and the DMV sweep is unlikely to catch the same instant.

The common case — an object that simply could not be resolved, with no reason recorded — already produces byte-identical labels on both sides, which is what [#1893] verified live.

Why it needs a decision rather than a patch

The obvious fix is to drop the reason from the incident identity while keeping it on the row. That is a real design question, not a tweak:

• The reason is currently part of what an alert says, not just what it groups by — IncidentGrouping uses one string for the identity, the Contentious Object detail field and InvolvedObjects. Splitting identity from display means the grouper carries two values where it carries one today.
• Two rows for the same object unresolvable for genuinely different reasons arguably ARE different situations, and collapsing them hides that a permission posture and a transient page move are not the same problem. That is a product call.
• Changing it churns report-side fingerprints for a fourth time. [blocked_process_report's object-resolution CATCHes say a row is Unresolved but never why #1865], [blocked_process_report and dmv_blocking_snapshots format contentious_object differently, so the merged blocking alerts fingerprint the same object twice #1876] and [The DMV blocking sentinel names the blocked session's database, not the lock resource's, so a cross-database lock still fingerprints twice #1893] have each moved them once already, all inside one release; a fourth ought to wait for a release where it is the only such change.

Not a regression. Before [#1876] these rows did not dedup at all.

[erikdarlingdata]

Closing as by-design: a report-side reason suffix (no metadata access vs page reallocated) describes genuinely different situations, so they alert separately on purpose. The common no-reason case fingerprints identically as of #1900, which was the real complaint. Reopen if field noise proves the distinction unhelpful - the change would be one grouper rule plus a fourth fingerprint transition, documented in this thread.