Mark stateless and servo meters when removed

[brharrington]

StatelessMeter and the five servo meter types implement RemovableMeter, so SwapMeter.get() reads the flag instead of falling back to hasExpired().

These are the two remaining registries whose expiry check reads the wall clock, so they are the two still paying for it on every update after #1290:

registry	hasExpired()	pays a clock read?
Atlas	now - lastUpdated > ttl	fixed in #1288
Stateless	clock.wallTime() - lastUpdated > ttl	yes → fixed here
Servo	now - lastUpdated.get() > EXPIRATION_TIME_MILLIS	yes → fixed here
Sidecar	return false	no
metrics3 / metrics5	return false	no
DefaultRegistry	return false	no

Servo has no shared meter base — ServoMeter is a functional interface for exposing monitors — so the field and two accessors are repeated across ServoCounter, ServoTimer, ServoGauge, ServoMaxGauge and ServoDistributionSummary. Stateless has a real base class, so it is one place.

Why the other three are left alone

Their hasExpired() is a constant false, so the instanceof fallback added in #1290 costs them nothing beyond the type test — there is no clock read to remove.

The exclusion is not purely about cost, though. Because they are not RemovableMeter, markRemoved is a no-op for them, so close()/reset() leaves a held reference bound to an orphan forever. That is unchanged from before this series and is not a regression, but adopting the flag there would be a behaviour improvement rather than a performance one, and belongs on its own terms.

Tests

StatelessRemovalMarkingTest (6) and ServoRemovalMarkingTest (5), all 11 failing with the production change reverted:

• every meter type is removable, asserted against the exact set of concrete classes
• a cleanup pass marks what it removes, and the meters are gone afterwards
• a meter that survives the pass is not marked, so "marks what it removes" is distinguished from "marks everything it visits"
• a held reference recovers from a removal with no time passing at all, so only the removal signal can explain it, and the update is asserted to land on the replacement rather than merely that a new meter appeared
• close() marking for stateless, which overrides it
• theWrapperAddsNoClockReadsOfItsOwn

The servo cleanup test drives ServoRegistry.getMonitors(), the registry's real cleanup entry point, rather than hand-rolling an iterator loop.

On the clock-read test: on servo an absolute count is the wrong assertion, because ServoCounter.add() reads the clock three times on its own — one per ServoPollers.NUM_POLLERS step bucket in DoubleCounter.increment, plus lastUpdated — and hard-coding that would break on any unrelated change to servo internals. Comparing the wrapper against the meter it delegates to pins the property that matters, that the wrapper adds nothing, and it fails on main where it adds exactly one read. It also asserts the measured floor is non-zero so two zeros cannot satisfy it. On stateless the raw meter reads exactly once, so that side pins the absolute count too.

Both registries keep bookkeeping counters of their own in the registry under test (ValidationHelper is wired to this with no way to redirect it), so the tests work from the ids they create rather than from everything the registry holds.