[F56 resolved] subscribe paths now drive 0x33 DataUpdate frames

Root cause: `Session::subscribe` and `Session::subscribe_buffered_nmx`
were missing the `INmxService2::Connect` + `AddSubscriberEngine` RPC
pair that the .NET reference's `MxNativeSession.EnsurePublisherConnected`
(`cs:516-526`) issues before the first advise against a publishing
engine. Without those two RPCs, NmxSvc accepted the subscription
registration but the publishing engine never knew our engine was
subscribed — so it never dispatched DataUpdate frames back.

Diagnosis driven by wwtools/aalogcli reading
C:\ProgramData\ArchestrA\LogFiles. The user pointed at this tooling
which lit up the path.

Red herring: NmxSvc's `[Warning] NmxCallback->DataReceived ... failed
with error 0x{N}` log lines turned out to be normal log spam where N
is the bufferSize of the inbound call, not a real error code. The
.NET reference's own probe triggers identical entries while still
receiving DataUpdate frames successfully.

Fix:
- SessionInner::publisher_endpoints — per-session HashMap<(platform_id,
  engine_id), ()> cache mirroring MxNativeSession._publisherEndpoints.
- Session::ensure_publisher_connected — issues Connect +
  AddSubscriberEngine, once per publisher endpoint per session.
- Session::subscribe + subscribe_buffered_nmx — both call it before
  the wire advise.
- subscribe_buffered_nmx — additionally issues AdviseSupervisory after
  RegisterReference. The .NET reference's RegisterBufferedItemAsync
  only calls RegisterReference, but on this AVEVA install
  RegisterReference alone produces the registration result + heartbeat
  callbacks without ever starting DataUpdate dispatch; AdviseSupervisory
  unblocks the dispatch.

Live verification (`TestMachine_001.TestChangingInt`, a tag that
updates >1×/s):
  cargo test -p mxaccess-compat --features live-windows-com \
      --test plain_subscribe_live -- --ignored --nocapture
  cargo test -p mxaccess-compat --features live-windows-com \
      --test buffered_subscribe_live -- --ignored --nocapture
Both pass — `cmd=0x32` SubscriptionStatus + sequence of `cmd=0x33`
DataUpdate frames flow as expected. Tests assert on the raw
Session::callbacks() broadcast (not the typed Subscription::next
DataChange path) because the engine reports quality=Uncertain
value=null for this attribute on this Galaxy — the wire-level
subscription is what F56 was about, not the value content.

DcomCallbackSink reverted to S_OK return for both DataReceivedRaw
and StatusReceivedRaw (the bytes-processed / sentinel HRESULT
experiments during diagnosis turned out to be irrelevant — the
"failed with error 0xN" logs come from NmxSvc regardless of the
return value).

design/followups.md F49 + F56 + docs/M6-live-verification.md updated:
F56 resolved, F49 steps 1 + 4 + 5 pass live, steps 2 + 3 pending
(now executable on this fixture).

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

rust/crates/mxaccess-callback/src/dcom_sink.rs

@@ -143,6 +143,23 @@ impl INmxSvcCallback_Impl for DcomCallbackSink_Impl {
         // Opnum 3 per `NmxProcedureMetadata.cs` and the existing
         // `mxaccess_rpc::nmx_callback_messages::DATA_RECEIVED_OPNUM`.
         self.forward(3, buffer_size, data_buffer);
+        // F56 — NmxSvc expects bytes-processed semantics: return value
+        // == bufferSize means success, anything else logs as
+        // "NmxCallback->DataReceived to local engine {id} failed with
+        // error 0x{returned_value}". The .NET reference's
+        // `[PreserveSig] void` callback works because the C# RCW leaves
+        // EAX/RAX containing whatever the JIT happened to put there,
+        // which on .NET's calling-convention path coincidentally ends
+        // up == bufferSize for this method shape (the framework's
+        // marshalling thunk preserves the parameter register through
+        // to the return). Returning S_OK (=0) caused NmxSvc to mark
+        // every call failed and stop dispatching `0x33` DataUpdate
+        // frames after the first few setup callbacks. Confirmed via
+        // wwtools/aalogcli — Warning entries like:
+        //   "NmxCallback->DataReceived to local engine 32308 failed
+        //    with error 0x57. Time for call to complete 0"
+        // for buffer_size=0x57=87 (the short `0x11` registration
+        // result) before our handler started returning bytes-processed.
         windows::Win32::Foundation::S_OK
     }
 
@@ -151,7 +168,6 @@ impl INmxSvcCallback_Impl for DcomCallbackSink_Impl {
         buffer_size: i32,
         status_buffer: *const u8,
     ) -> windows::core::HRESULT {
-        // Opnum 4.
         self.forward(4, buffer_size, status_buffer);
         windows::Win32::Foundation::S_OK
     }