merge: tag-resolution counts fixed on first subscribe (register row 55) — HandleSubscribeCompleted was the missing fourth UpdateTagResolution push site, so a perfectly healthy connection reported 0/0 forever

src/ZB.MOM.WW.ScadaBridge.DataConnectionLayer/Actors/DataConnectionActor.cs

@@ -1285,6 +1285,20 @@ public class DataConnectionActor : UntypedActor, IWithStash, IWithTimers
         // Fire-and-forget release of every handle this request created redundantly.
         _ = UnsubscribeIdsAsync(_adapter, redundantIds);
 
+        // Publish the resolution counts this request just changed. Without this push a
+        // connection whose tags ALL resolve on the first attempt reported 0/0 forever:
+        // the only other pushes are BecomeConnected's (which fires before any instance
+        // has subscribed, so its 0/0 is legitimate but is never superseded),
+        // HandleBatchSubscribeCompleted's (reconnect re-subscribe / resolution probe) and
+        // HandleUnsubscribe's (teardown) — and ScheduleTagResolutionRetry below cancels
+        // the retry timer outright when nothing is unresolved, so no later tick pushed
+        // either. The blind spot was therefore worst on a perfectly healthy connection,
+        // which is precisely when the "device still booting / tag path unresolved"
+        // diagnostic is supposed to read clean rather than empty. Mirrors the push site
+        // in HandleBatchSubscribeCompleted, and stays on the actor thread where both
+        // derived counts are stable.
+        _healthCollector.UpdateTagResolution(_connectionName, TotalSubscribedTagCount, ResolvedTagCount);
+
         // Now that every tag is registered in
         // _subscriptionsByInstance, deliver the values captured by the initial read.
         // Re-entering via Self reuses HandleTagValueReceived's generation guard, fan-out