sp_HumanEventsBlockViewer: resolve the contended object from wait_resource

[erikdarlingdata]

contentious_object was ~99% "Unresolved: ... object_id: N" because it resolved OBJECT_NAME() against the blocked-process-report event's object_id field, which is unreliable for KEY/PAGE/RID lock waits (reports 0 or a non-object id). This decodes the lock resource from wait_resource instead:

• KEY -> hobt_id via [db].sys.partitions -> object_id (per contended database, dynamic SQL)
• OBJECT -> object_id directly
• PAGE/RID -> sys.dm_db_page_info (2019+ or Azure SQL DB; VIEW DATABASE STATE) -> object_id

Non-object locks (DATABASE / XACT / METADATA / ...) and anything that can't resolve keep the Unresolved sentinel the findings + output logic depends on. Resolved values stay plain schema.object so the @object_name filter still matches. The event object_id is kept as a COALESCE fallback so nothing that resolved before regresses. Compound waitresources (XACT: ... KEY: ...) resolve off the embedded token.

Adds @product_version (PARSENAME of ProductVersion, matching the QuickieStore idiom) to gate dm_db_page_info; cross-db lookups are per-database dynamic SQL (QUOTENAME'd, parameterized via sp_executesql, with TRY/CATCH for the page-info permission and DB-online guards). TRY_CONVERT makes the string parse unthrowable; lock_type is varchar(32) so long resource tokens (APPLICATION / ALLOCATION_UNIT) can't overflow.

Validated on SQL Server 2025 (HammerDB): contentious_object resolution ~0.3% -> ~97% on the full history; end-to-end, KEY locks resolve to dbo.district/new_order/order_line/customer, unresolvable PAGE/non-object locks labeled honestly.

Known follow-up (not in this change): the bpr_with_lead chain-lead rollup still derives contentious_object from the event object_id for its @object_name filter -- moot unless @object_name is explicitly passed, and not a regression.

🤖 Generated with Claude Code