Log process memory at the end of each collection cycle

[erikdarlingdata]

Summary

Add a single INFO log line at the end of every collection cycle reporting Working Set, Private Bytes, and GC heap.

Why

Two-fold motivation, both surfaced by #933:

1. Self-reporting for bug reporters. When OP filed [BUG] Memory usage on client #933 about high memory, they had to read the number off Task Manager. With this in place, the answer is in the log they're already pasting.
2. Continuous trace for regression diagnosis. During the recent investigation we had to sample memory externally (PowerShell every 30 s) to confirm the fix worked. With this line in the log, future memory regressions show up directly in the file we already collect from users.

Implementation

• CollectionBackgroundService.LogProcessMemory() — three property reads, called after RunArchivalIfDueAsync and RunRetentionIfDue so it captures the cycle's quiescent state, not a mid-archival spike.
• Errors swallowed at DEBUG level so a transient inability to read process stats never breaks the collection loop.

Output

One line per minute, format:

[CollectionBackgroundService] Process memory: WS=350 MB, Private=215 MB, GC heap=42 MB

• WS = working set (what Task Manager shows)
• Private = private bytes (unique-to-process, the honest "actual RAM cost")
• GC heap = .NET managed heap only — WS - Private - GC is rough native/shared overhead

Test plan

• Builds clean
• Run Lite, watch the log emit one memory line per cycle
• Confirm cadence doesn't cause log volume problems (1440 lines/day at default 1-min cadence)

🤖 Generated with Claude Code