AMBARI-26661. Refresh telemetry assignments on component state transitions (#4222)

TelemetryHolder only refreshes a host's telemetry assignment in response to
ServiceComponentInstalledEvent, which ServiceComponentHostImpl publishes from
its constructor while the host component row is first persisted with desired
state INIT. TelemetryAssignmentCompiler skips any component that is not in an
installed state - and INIT is not one of them - so the assignment compiled at
that moment never contains component targets.

Nothing recompiles it on the normal install/start path either: handleEvent(),
which processes the real state transitions, refreshes HostLevelParamsHolder but
never TelemetryHolder. A freshly installed cluster therefore gets no VMAGENT
component scrape targets until an unrelated cluster config change or an
ambari-server restart forces a recompile.

Refresh TelemetryHolder from handleEvent(), in the same block that already
publishes HostComponentsUpdateEvent on a real status change. TelemetryHolder
.getCurrentData(Long) is widened from protected to public so it is callable
from there, matching how HostLevelParamsHolder already exposes it.

Adds two tests:
- TelemetryAssignmentCompilerTest asserts a component in INIT contributes no
  targets while INSTALLED and STARTED each contribute one, documenting why
  subscribing to ServiceComponentInstalledEvent cannot work.
- ServiceComponentHostTest asserts a real state transition repopulates the
  host's telemetry assignment. The cached assignment is dropped after
  createEvent(), because creating a config publishes ClusterConfigChangedEvent,
  which TelemetryHolder also refreshes on - the same mechanism that masks this
  bug on a real cluster.