RDKC-16495: telemetry(DCMAGENT) async-subscribe to DCM Reloadconfig T2 - DCM

[rdkcteam]

On RDK-C (sysvinit), telemetry2_0 starts well before dcmd, so telemetry's one-shot synchronous rbusEvent_Subscribe(T2_DCM_RELOAD_EVENT) to dcmd's reload provider fails permanently with "no provider" (err 20) and never retries → dcmEventStatus stays 0, telemetry never publishes Setconfig/Processconfig, and dcmd sits idle. systemd platforms (video/STB) hid this via Before= ordering.
Fix
In registerRbusDCMEventListener() (source/ccspinterface/rbusInterface.c), replace the one-shot sync subscribe with rbusEvent_SubscribeAsync(...) + a new rbusDCMReloadSubscribeHandler callback. rbus retries the subscription in the background until dcmd registers the reload element — the same async mechanism telemetry already uses for Device.DCM.Setconfig/Processconfig. The handshake no longer depends on which daemon starts first.

•	Entirely inside #ifdef DCMAGENT → compiled out on every non-camera build.
•	SubscribeAsync is a strict superset of Subscribe; where the provider is already up (systemd), it completes on the first attempt → identical behavior.
•	rbusReloadConf handler and dcmEventStatus gating unchanged.

[Copilot]

Pull request overview

This PR updates the DCM reload-config RBUS event subscription logic (DCMAGENT builds) to avoid a startup ordering issue where telemetry can start before dcmd on sysvinit platforms, causing a one-shot synchronous subscribe to fail permanently.

Changes:

• Added an async subscribe-response callback (rbusDCMReloadSubscribeHandler) to report eventual subscribe success/failure.
• Replaced rbusEvent_Subscribe(...) with rbusEvent_SubscribeAsync(...) for T2_DCM_RELOAD_EVENT to allow background retry until the provider is available.