Merge #610: server-side array writes gated per driver capability (DriverArrayWriteSupport); ArrayWritable on the surgical whitelist + UNS Backing; shape/IndexRange refusal; ValueRank>1 out of scope

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

# Conflicts:
#	docs/drivers/S7.md

docs/drivers/S7.md

@@ -255,12 +255,13 @@ read is byte-granular, so a matching write would overwrite the 7 neighbouring bi
 touches, and a safe bit-packed write needs read-modify-write. Mark Bool arrays `writable: false`. A `null` array element is rejected (`BadTypeMismatch`, nothing written)
 rather than coerced to 0. An array write larger than one PDU is split by S7.Net into several writes and is
 **not atomic** — a mid-write failure can leave the PLC array partly updated.
-Note the *server* still presents every array node read-only to OPC UA clients ([Uns.md §Array
-tags](../Uns.md#array-tags-1-d), #610 item 1) — the driver path is reachable today through the Client
+The server exposes these as **writable OPC UA array nodes** (#610) for exactly the element types above —
+a `Bool` / wide-type S7 array stays read-only at the node (`BadNotWritable`), see [Uns.md §Array
+writes](../Uns.md#array-writes-610). The driver path is also reachable directly through the Client
 CLI / driver-level callers and is proven by the unit suite plus the snap7 fixture test
 (`S7_1500ArrayWriteTests`); the AdminUI tag editor rejects wide-type and writable-Bool arrays at author time.
 
-**Deferrals** — server-side exposure of array writes, multi-dimensional arrays, per-element historization,
+**Deferrals** — multi-dimensional arrays (out of scope by decision, see Uns.md), per-element historization,
 wide-type array elements (`Int64`, `UInt64`, `Float64`, `String`, `DateTime`), and
 Timer/Counter array elements.