Blocking/deadlock XML processors truncate parsed data every run

[erikdarlingdata]

Bug

Both collect.process_blocked_process_xml and collect.process_deadlock_xml TRUNCATE their respective parsed output tables (blocking_BlockedProcessReport and deadlocks) on every scheduled run, then re-parse all raw XML from scratch.

The scheduler calls both processors with no @start_date/@end_date, which hits the TRUNCATE path at line 143 in both procedures. The date-range code path that would preserve parsed data exists but is never used.

Impact

• Parsed blocking/deadlock data is wiped and rebuilt every 5-10 minutes
• As raw XML ages out of 30-day retention, the corresponding parsed data is permanently lost on the next re-parse cycle
• Wasted CPU re-parsing identical XML every cycle (currently 61 raw rows re-parsed every run)
• The parsed table can never contain events older than what's currently in the raw XML table

Fix

Add an is_processed flag to the raw XML tables (collect.blocked_process_xml and collect.deadlock_xml). Processors will:

1. Only count/process rows where is_processed = 0
2. Derive @start_date/@end_date from unprocessed rows (using the existing date-range code path)
3. Mark rows as is_processed = 1 after successful parsing

This allows parsed data to accumulate over time and eliminates redundant re-parsing.

Also fixes a Lite bug: blocked_process_reports is missing from ArchiveService.cs archival list, causing blocking data to accumulate indefinitely.

[erikdarlingdata]

Fixed in feature/23-is-processed-tracking, merged to dev. Blocking/deadlock XML processors now use is_processed tracking instead of TRUNCATE-and-reparse. Tested via CLI installer (52/52, 0 failures) and verified end-to-end on sql2022.