Find a better home for metrics tied to components' lifecycle

PR #25910 fixed vector_security_confinement_disabled expiring by storing Gauge handles in RunningTopology::sink_confinement_gauges. It works, but it's a band-aid:

• RunningTopology now has to know about a specific metric's lifecycle, which is the wrong layer of abstraction.
• Any future one-shot build-time gauge would need the same treatment. Another field in RunningTopology and another ad-hock hook inside topology code.

The right fix is a general mechanism where a component can register a metric handle that is tied to its lifetime, without the topology needing to know what the handle is. Options worth exploring:

• A handle bag in SinkContext (or a shared ComponentContext) that the topology drains and holds per component key.
• A trait-level hook (e.g. fn static_metric_handles(&self) -> Vec<Box<dyn Any>>) so the topology can hold arbitrary handles opaquely.

Start by reading the lifecycle handling around RunningTopology::sink_confinement_gauges and the component context options named in the issue: SinkContext or ComponentContext. Compare a handle bag with the proposed trait-level hook, then determine how handles can be retained per component without topology-specific metric fields. Done means one general lifecycle mechanism replaces the current special case and supports future one-shot build-time gauges.