feat(drivers): every driver reports the authored tags it skipped (Gitea #541)

A driver builds its RawPath -> definition table at init and tolerates a
per-tag miss: an unmappable TagConfig, an unparseable address, a
capability-matrix rejection. That tolerance is right -- one bad tag must not
take down the other few thousand. What was missing is any statement of the
fact afterwards. A skip is not an error and happens before any read, so the
driver stays Healthy, errors/5 min stays 0, Last error stays empty, and Last
read advances live off the tags that did map. On the wonder Makino in #540
that reading held while focas-z-34184 ignored 20 of its 22 tags.

New optional capability ISkippedTagReporter, backed by a shared
SkippedTagLedger so the reset/commit/cap rules are one implementation rather
than one per driver. The report -- authored count, exact skipped count, and a
capped sample of RawPath + reason -- rides DriverHealthChanged to a new Tags
column on /hosts, over the Phase 5 telemetry stream. No table: a driver-only
node has no ConfigDb to write to, the lesson from #521.

The issue named eight drivers. It is twelve -- every driver in
DriverTypeNames.All has an authored-tag skip path. Calculation (no scriptId),
MTConnect (no readable DataItem id), Galaxy (no attributeRef) and OpcUaClient
(no nodeId) were unlisted, and OpcUaClient's was the quietest of the twelve:
NamespaceMap drops such an entry with a bare `continue` and not even a log
line. SkippedTagReporterFleetTests pins the invariant reflectively over every
IDriver in src/Drivers/, so a thirteenth cannot re-introduce the silence.

Sql drops a tag at TWO points and its report is the union of both: a blob
that does not map, AND an identifier the 8.1 catalog gate rejects against the
live catalog. The second is what schema drift produces -- a renamed column, a
dropped view -- months after a deployment sealed green, and reporting only
the first would have that driver claim "0 skipped" while polling half its
tags, which is worse than reporting nothing because the column would then be
actively reassuring.

Deliberately additive to driver state, never a change of it. Latching
non-Healthy for a config problem would satisfy both halves of the #527
comms-loss conjunction -- 90 s without a successful read AND non-Healthy --
and a driver whose tags were ALL skipped has no successful reads by
construction, so it would reconnect-loop forever against a healthy device.

Three details that are load-bearing rather than incidental:

- The skip digest is part of the publish fingerprint. A skipped tag leaves
  every other fingerprint component identical to a clean driver's, so without
  it PublishHealthSnapshot's dedup swallows exactly the publish carrying the
  signal -- the trap that already bit the rediscovery and host-status
  channels. The digest covers the sample, not just the counts: a redeploy
  that fixes one tag and breaks another leaves both counts unchanged.
- The count is exact; only the sample is capped, and the tooltip says so when
  it is showing fewer than it counted. A truncated list that looked complete
  would have an operator fix twenty tags and believe the job done.
- The ledger stages and commits, so an init that throws part-way leaves the
  previous report standing. A partial snapshot would read as "we now skip
  fewer tags", the opposite of the truth.

The proto field needs no companion presence flag, unlike host_statuses: a
singular message field carries real presence in proto3, and a has_ flag would
collide with protoc's generated HasSkippedTags.

Verified red-first three ways: dropping SkippedTagDigest from the fingerprint
fails the two dedup tests, removing the seam from one driver fails the fleet
guard, and dropping the catalog-gate leg fails the Sql union test. Full
solution builds with zero new warnings against 4e22f024.

src/Core/ZB.MOM.WW.OtOpcUa.Commons/Protos/telemetry.proto

@@ -76,6 +76,27 @@ message DriverHealth {
   // than letting an empty list silently claim the driver has no probe.
   bool has_host_statuses = 10;
   repeated HostConnectivity host_statuses = 11;
+  // Authored tags the driver could not build into its poll table (Gitea #541). The same two facts
+  // host_statuses needs a flag for — "the driver cannot report skips" vs "it reports none" — are
+  // distinguished here by the field's own presence: a singular MESSAGE field has real presence in
+  // proto3, which a repeated field does not. So no companion has_ flag (and one would collide: protoc
+  // already generates a HasSkippedTags property for this field).
+  SkippedTags skipped_tags = 12;
+}
+
+// Mirrors ZB.MOM.WW.OtOpcUa.Core.Abstractions.SkippedTagReport.
+message SkippedTags {
+  int32 authored_count = 1;
+  // The TRUE total, which may exceed sample.length — the detail list is capped so a deployment that
+  // misconfigures thousands of tags cannot inflate a message published on every state change.
+  int32 skipped_count = 2;
+  repeated SkippedTag sample = 3;
+}
+
+// Mirrors ZB.MOM.WW.OtOpcUa.Core.Abstractions.SkippedTag.
+message SkippedTag {
+  string raw_path = 1;
+  string reason = 2;
 }
 
 // Mirrors ZB.MOM.WW.OtOpcUa.Core.Abstractions.HostConnectivityStatus.