fix(ablegacy): deterministic NotSupported refusals are BadNotSupported with no health write

Review 07 H16: an array of String/Timer/Counter/Control passed the mapper, so
every poll created a handle (one init read), the decode threw
NotSupportedException, the generic catch evicted the handle and latched
Degraded. FromTagConfig now rejects that combination (the skip carries the
reason, Inspect/deploy gate and the AdminUI model state it), and a runtime
NotSupportedException on read or write is BadNotSupported: handle kept, no
health write, one Warning per tag and operation. Write refusals (native PLC-5
and status-bit writes, libplctag translated addresses) now warn once per tag too.

Refs #738
Claude-Session: https://claude.ai/code/session_01Ub9hGmYLQvn9XETzw7CMsT

src/Server/ZB.MOM.WW.OtOpcUa.AdminUI/Uns/TagEditors/AbLegacyTagConfigModel.cs

@@ -87,6 +87,11 @@ public sealed class AbLegacyTagConfigModel
         if (isArray && arrayLength > AbLegacyArray.MaxElements)
             return $"AbLegacy array length cannot exceed {AbLegacyArray.MaxElements} (PCCC data-file element limit).";
 
+        // Same rule the reader enforces (review 07 H16): structured elements never form an array. Stated here so
+        // the CSV-import / API paths get the specific reason instead of the parse gate's generic one.
+        if (isArray && arrayLength >= 1 && !AbLegacyTagDefinitionFactory.IsArrayElementTypeSupported(DataType))
+            return AbLegacyTagDefinitionFactory.ArrayElementTypeError(DataType);
+
         // Parse-gate backstop: the checks above mirror the reader's whole rejection surface today, so this is
         // expected to be silent for AbLegacy. It is here so a future reader rule cannot become a gap.
         return TagConfigParseGate.Describe(