Clarify scope of `valid_unit_periods` extension and the `periods` argument in metric extensions

I am working on ndx-spikesorting with @alejoe91, where I am mapping the concept of intervals in SpikeInterface to NWB. I want to ask three design questions about the scope of valid_unit_periods and the periods argument in the metric extensions:

1. On the role of valid_unit_periods's output: is its per-unit interval output valuable as standalone data (for visualization via ValidUnitPeriodsWidget, curation decisions, downstream user analyses outside SpikeInterface), or is its only purpose to produce intervals that restrict the computation of metric extensions?

2. On interval calculation: should valid_unit_periods remain the only extension that calculates per-unit intervals, or should multiple extensions for different algorithms (Bombcell-style criteria, drift-aware variants, faithful npyx ports, etc.) coexist as siblings?

3. On the periods= argument: should quality_metrics (and spiketrain_metrics) accept only intervals from quality-driven sources like valid_unit_periods, or also arbitrary intervals (behavioral epochs, trial structure, drift-corrected windows, etc.)? What was the intent here?

From reading the code, my current interpretation is:

1. valid_unit_periods is the canonical (and only expected) source of per-unit time intervals; the meaning of these intervals is generically "times where the sorting is good."
2. The metric extensions' periods= argument is meant to consume intervals only of that type: "times where the sorting is good."

Having these clarified would help me map the SpikeInterface structures to NWB cleanly.

Start by reviewing the valid_unit_periods extension and the periods arguments in quality_metrics and spiketrain_metrics. Compare the issue's three design questions with the current code and explain whether intervals are canonical quality periods or may be arbitrary. Done means the intended scope and sibling-extension model are decided clearly enough to guide the NWB mapping.