[CmdPal] Fix memory leak in PerformanceWidgetsPage network band items

[michaeljolley]

Summary

Fixes a memory leak in the Performance Monitor dock extension where GetItems() created new ListItem instances for _networkUpItem and _networkDownItem on every call.

Problem

When the dock subscribes to ItemsChanged and calls GetItems() to refresh, the band page path allocates 2 new ListItem objects each time — the old ones are replaced in the fields but never collected (they remain referenced by the DockItemViewModel wrappers until the next refresh cycle). Under normal operation this leaks ~2 objects/second indefinitely.

Fix

Move _networkUpItem/_networkDownItem creation into the constructor (matching the pattern used by CPU, Memory, GPU, and Battery items). GetItems() now returns stable references. The Updated event handler already updates their .Title properties, which propagates to the UI via PropChanged → CommandItemViewModel.Model_PropChanged.

Validation

• Build succeeds (Microsoft.CmdPal.Ext.PerformanceMonitor.csproj)
• Network up/down band items still receive title updates via the existing Updated handler
• No RaiseItemsChanged() needed — ListItem.Title setter fires PropChanged, which DockItemViewModel already observes

[Copilot]

Pull request overview

Fixes a memory leak in the CmdPal Performance Monitor dock/band experience by ensuring the network up/down band items are stable objects rather than being re-created on every GetItems() refresh. This aligns the network band item lifecycle with the existing CPU/Memory/GPU/Battery patterns and avoids accumulating stale wrappers over time.

Changes:

• Create _networkUpItem and _networkDownItem once in the constructor when isBandPage is true.
• Remove the per-refresh allocation of those items from GetItems(), returning stable references instead.