docs: refresh stillpending.md for completed work; record residuals (§7/E2)

Mark §1.1 (11 worker commands), §1.2 (audit CorrelationId), and §4 client
CLI/helper parity as Resolved with commit refs; correct §4.4 (dotnet version
already worked). Record open residuals: §1.3 live failover counter, §3.2
multi-sample buffered conversion, §1.4 vendor-stub ack, DrainEvents snapshot
semantics.

docs/plans/2026-06-14-deferred-followups.md

@@ -268,3 +268,34 @@ the deployed instance. **No source change made** (no-op).
 deployed instance (the only path that exercises routing past the unauthenticated 302-to-`/login`).
 Recommend a spot-check of authenticated `GET /` after the next Server redeploy; if it returns 200
 (not 500), this item can be fully closed.
+
+---
+
+## Recorded residuals after `feat/stillpending-completion` (2026-06-15)
+
+The stillpending.md actionable items were implemented on branch `feat/stillpending-completion`
+(see `docs/plans/2026-06-15-stillpending-completion.md`). These environment/vendor-gated residuals
+remain explicitly open — none are code defects:
+
+- **`provider_switches{from,to,reason}` counter — live exercise still pending.** The metric is
+  emitted on the alarm failover/failback path and unit-tested, but the dev rig's object-driven
+  alarms can't be made to fail a real alarmmgr→subtag switch from outside, so the `reason` tagging
+  is unproven against a live failover. Re-verify when a rig (or capture) can drive an actual
+  alarmmgr fault. (stillpending §1.3.)
+
+- **`DrainEvents` is a diagnostic snapshot, not an exhaustive drain.** The worker now answers
+  `DrainEvents` (handled in `WorkerPipeSession`, off-STA), but it pulls from the same event queue
+  that the ~25 ms background stream-drain loop continuously empties. With an active event stream a
+  `DrainEvents` caller therefore receives only events not yet pushed by the stream loop — there is
+  no loss or double-delivery (the queue drain is lock-protected and destructive), but the result is
+  a non-deterministic snapshot. Documented here so the semantics aren't mistaken for a bug.
+
+- **Buffered multi-sample conversion (`OnBufferedDataChange`) — unverified live.** `AddBufferedItem`
+  / `SetBufferedUpdateInterval` are implemented and live-confirmed; the empty `NoData` bootstrap
+  event converts cleanly live (`f7ada90`). A real parallel quality/timestamp sample batch
+  (length > 1) is undrivable on the current rig, so the multi-sample path is exercised only by unit
+  tests against a fake `IMxAccessServer`. (stillpending §3.2.)
+
+- **8-arg alarm ack operator `domain`/`full_name` — vendor-blocked.** The AVEVA `IwwAlarmConsumer2`
+  8-arg `AlarmAckByName` returns −55 (stub) and `AlarmAckByGUID` is `E_NOTIMPL` on this build, so the
+  two fields stay forward-compat-only on the wire. (stillpending §1.4 / §3.4 / §3.5.)