Add bulk read/write command family across worker, gateway, and clients

Adds five new MXAccess command kinds (WriteBulk, Write2Bulk,
WriteSecuredBulk, WriteSecured2Bulk, ReadBulk) that ride the existing
"one round-trip, per-entry results" bulk shape used by AddItemBulk and
SubscribeBulk today. MXAccess COM has no native bulk API; the worker
runs each bulk operation as a sequential loop on its STA, returning
one BulkWriteResult / BulkReadResult per requested entry so per-item
MXAccess failures surface as was_successful=false rather than throwing.

ReadBulk has no MXAccess analogue. The worker satisfies it by:

  - Returning the last cached OnDataChange payload (was_cached=true)
    when the requested tag is already in the session''s item registry
    AND advised — the existing subscription is NOT touched, since the
    caller did not create it.
  - Otherwise taking the AddItem + Advise + wait-for-OnDataChange +
    UnAdvise + RemoveItem snapshot lifecycle itself (was_cached=false)
    and leaving the session exactly as it was. The wait pumps Windows
    messages on the STA so the inbound MXAccess event can dispatch
    while the executor still holds the thread.

The new MxAccessValueCache lives on each MxAccessSession, shared with
MxAccessBaseEventSink which populates it on every OnDataChange after
the event clears the outbound queue. Eviction on RemoveItem keeps
reused MXAccess handles from serving stale values from a previous
lifetime.

Gateway-side authorization wires WriteBulk/Write2Bulk to invoke:write,
WriteSecuredBulk/WriteSecured2Bulk to invoke:secure, ReadBulk to
invoke:read. The constraint-filter pipeline is refactored from a single
BulkConstraintPlan record into an abstract base plus three concretes
(SubscribeBulk, WriteBulk, ReadBulk), each owning its own denied-entry
merge so the dispatch site never branches on reply shape. A new
FilterWriteBulkAsync<TEntry> generic over the four write-entry shapes
runs CheckWriteHandleAsync per entry; denied entries surface as the
BulkWriteResult shape, preserving original-index order.

All five language clients (.NET, Go, Rust, Python, Java) gained the
five new methods following their existing bulk pattern, with regenerated
protobufs.

Tests added:
  - MxAccessValueCacheTests (6 cases) — Set/TryGet, Remove resets the
    version, TryWaitForUpdate signals on Set, pump step fires each poll.
  - MxAccessBaseEventSinkTests — OnDataChange populates the cache,
    ValueCache property exposes the bound instance.
  - MxAccessCommandExecutorTests — four bulk-write variants (per-entry
    success/failure, value+timestamp forwarding, secured user ids),
    ReadBulk snapshot lifecycle on uncached tag (timeout surfaces as
    was_successful=false), invalid-payload reply.
  - GatewayGrpcScopeResolverTests — five new MxCommandKind cases.
  - SessionManagerTests — WriteBulk and ReadBulk forwarding through
    FakeWorkerHarness; ReadBulk forwards timeout_ms.
  - Per-client (.NET, Go, Rust, Python, Java) — WriteBulk builds the
    right command and returns per-entry results, ReadBulk forwards the
    timeout and unpacks the was_cached flag.

Cross-language e2e CLI subcommands for the new bulks are deliberately
scoped out of this change (each of the five client CLIs would need
five new subcommands plus matching phases in
scripts/run-client-e2e-tests.ps1); coverage equivalent to the existing
bulk-subscribe coverage is provided by worker + gateway + per-client
unit tests.

Docs updated in the same commit: gateway.md (Public MXAccess Command
Surface), docs/DesignDecisions.md (new "Bulk Command Family" section
with the ReadBulk cache-then-snapshot rationale), and every client
README.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/DesignDecisions.md

@@ -199,6 +199,57 @@ and failure behavior are easy to compare against direct MXAccess.
 
 Batch tag registration can be added later if measured setup latency requires it.
 
+## Bulk Command Family
+
+Decision: the gateway exposes a fixed set of *bulk* command kinds —
+`AddItemBulk`, `AdviseItemBulk`, `RemoveItemBulk`, `UnAdviseItemBulk`,
+`SubscribeBulk`, `UnsubscribeBulk`, `WriteBulk`, `Write2Bulk`,
+`WriteSecuredBulk`, `WriteSecured2Bulk`, `ReadBulk` — that carry a list of
+entries in one round-trip and return one per-entry result. Each command kind
+runs the corresponding single-item MXAccess COM call sequentially on the
+worker STA; per-entry failures populate `was_successful = false` with the
+underlying HRESULT and never throw. There is no transactional / fail-fast
+semantic — bulk here means "one round-trip, per-entry results", not
+"atomic".
+
+Rationale: MXAccess COM itself has no native bulk API for any of these
+operations. Surfacing the per-entry result list keeps parity transparent —
+the caller sees the same per-item HRESULT they would see calling MXAccess
+N times directly — while the bulk shape collapses the gateway/IPC overhead
+to one round-trip per batch and lets the worker keep the STA hot.
+
+`ReadBulk` is the only bulk command without a 1:1 MXAccess analogue. Two
+choices were considered:
+
+1. **Cache-then-snapshot** (chosen): when a requested tag is already in the
+   session's item registry AND advised, the worker returns the last cached
+   `OnDataChange` value without touching the subscription
+   (`was_cached = true`). Otherwise it takes the full `AddItem + Advise +
+   wait-for-first-OnDataChange + UnAdvise + RemoveItem` lifecycle itself
+   (`was_cached = false`) and leaves the session exactly as it was before
+   the call. The cache lives on a per-session `MxAccessValueCache`,
+   populated by `MxAccessBaseEventSink` on every `OnDataChange` after the
+   event clears the outbound queue.
+
+2. **Always-snapshot**: take the AddItem-through-RemoveItem lifecycle for
+   every requested tag. Cleaner conceptually but pays the full lifecycle
+   cost on every call and would interfere with existing subscriptions if
+   MXAccess reuses item handles.
+
+The chosen behavior matches what callers actually want from "current
+value" — a free read of an already-streaming tag, and a one-shot snapshot
+otherwise — and never disturbs subscriptions the caller did not create.
+The decision intentionally does NOT synthesize an `OnDataChange` event
+from the snapshot path: the snapshot value reaches the caller through
+`ReadBulk`'s reply payload only, not through the event stream. This
+preserves the "Don't synthesize events" rule that scopes the rest of the
+worker.
+
+`ReadBulk`'s wait loop pumps Windows messages on the worker STA
+(`StaRuntime.PumpPendingMessages`) on every poll iteration so the inbound
+MXAccess COM event can dispatch while the bulk executor still holds the
+thread — without the pump the OnDataChange would never deliver.
+
 ## Graceful Worker Shutdown
 
 Decision: best-effort cleanup before COM release.