Merge #855 shared per-report event projection: Lock hold back near pre-#855 at N=50

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

docs/plans/2026-11-11-folder-event-per-item-delivery.md

@@ -100,3 +100,37 @@ The per-event verdict for folder items moves from the SDK's consumer task (cache
   ConditionRefresh2, resubscribe), the gate race, newer-than-cut replay, ACL omission not withheld, ACL revocation during
   deferral, the in-flight suspended event, and two stress tests (production overload with no stall; stall + refresh +
   reports concurrently).
+
+## Follow-up: cost under `Lock` (projected delivery)
+
+Measured with `FolderEventDeliveryPerfTests` (opt-in, `OTOPCUA_EVENT_PERF=1`): the per-item work moved under `Lock` by
+this change cost ~5–6 µs/item publishing and ~10–30 µs/item at a full queue (N = 50 stalled items: p50 0.4–1.6 ms).
+Profiling split it into the SDK's role-permission check (~3–9 µs/item) and `MonitoredItem.QueueEvent(IFilterTarget)`,
+whose duplicate scan over the last ≤ 1000 queued events grows with the queue (~3 µs at QueueSize 10, ~10–16 at 1000,
+~16–31 at 10 000) on top of the per-item where-clause + select-clause projection.
+
+`ProjectedEventDelivery` / `EventDeliveryCache` (per report, hung on the condition snapshot, dropped when the walk ends):
+
+- the SDK role verdict once per (session, effective identity); the #826 grant check once per identity per hop;
+- the where clause and the select-clause projection once per (value-equal `EventFilter`, preferred locales), in the
+  SDK's order (fields only for an item that will queue) — filters are grouped once per filter object (`Utils.IsEqual`,
+  ≤ 4096 shared groups, then private groups, counted); a group evaluates its OWN deep clone, validated once, under its own
+  lock, never an item's filter object — and the field values shared read-only by every item queued from it (each item still gets its own `EventFieldList`: the SDK rewrites a queued list's
+  `ClientHandle` on modify);
+- the SDK's `QueueEvent(instance, false)` body reproduced under the item's own lock (event item; Disabled ⇒ nothing;
+  duplicate ⇒ nothing — asked of the report's "already queued" set instead of the queue; the filter in use;
+  `SetQueueOverflowIfFull`; then the public `QueueEvent(EventFieldList)`), reading three private members (`m_lock`,
+  `m_eventQueueHandler`, `FilterToUse`) — pinned by a guard test; anything else (members missing, a subclassed item, a
+  non-`EventFilter` filter, a `SupportsFilteredRetain` condition, a non-snapshot event, refresh replays) uses the SDK's
+  own `QueueEvent(IFilterTarget)`.
+
+`ProjectedEventDeliveryWireTests` runs one scenario through each path (`UseProjectedEventDelivery`, which also turns the
+verdict sharing off) and requires
+identical streams on folder and Server-object items (value-equal filters, a severity where clause, an OfType where
+clause with an absent field, the same select list under three where clauses, a filter modified mid-run, a second session
+with other locales, an ungranted anonymous Server-object item, a Disabled item) plus a small overflowing queue with
+DiscardOldest true and false; it fails if the where clause, a field or the grouping is wrong.
+
+Residual: at a full queue the SDK's own `EventMonitoredItemQueue` still does `List.RemoveAt(0)` per item (memmove of the
+whole queue) — ~1–10 µs/item at QueueSize 1000–10 000; replacing the queue (`IMonitoredItemQueueFactory`) is a separate
+change.