diff --git a/docs/M6-buffered-evidence.md b/docs/M6-buffered-evidence.md
index 1a978e1..6d3a2da 100644
--- a/docs/M6-buffered-evidence.md
+++ b/docs/M6-buffered-evidence.md
@@ -95,12 +95,7 @@ throws `ArgumentException("Suspend requires an advised item handle")`).
    Consequently no `0x32`/`0x33` frame in 077's TCP capture corresponds to
    the suspend; the capture has nothing to falsify.
 
-**R5 boundary that is still unproven.** Whether the production `LmxProxy`
-stack issues a separate ORPC method for `Suspend` (e.g. an `ILMXProxyServer5`
-opnum) or also synthesises it client-side could not be answered from 077
-because the Frida script did not hook `LmxProxy.dll!CLMXProxyServer.Suspend`.
-A follow-up capture with that hook installed would close the residual gap;
-filed as **F45** below.
+**R5 boundary** (was unproven at the time of this evidence walk; see "Sub-followup F46 — RESOLVED" below). Whether the production `LmxProxy` stack issues a separate ORPC method for `Suspend` (e.g. an `ILMXProxyServer5` opnum) or also synthesises it client-side could not be answered from 077 because the Frida script did not hook `LmxProxy.dll!CLMXProxyServer.Suspend`. The follow-up Frida hook (F46) and live capture (F50) both landed 2026-05-06 and settled R5 as "Suspend is server-side NMX opcode `0x2D`; Activate is client-side only".
 
 ## 079 — Buffered + supervisory advise
 
@@ -274,16 +269,16 @@ Per F44 DoD step 2 ("if a multi-sample body is observed, surface a typed
   carry the verbatim inner-body bytes of capture 094 lines 48 and 145 for
   reproducibility.
 
-## Sub-followup filed: F45
+## Sub-followup F46 — RESOLVED 2026-05-06
 
-A residual gap remains at the LMX-proxy boundary: capture 077 did not
-instrument `LmxProxy.dll!CLMXProxyServer.Suspend` / `.Activate`, so we cannot
-say whether the production stack issues a dedicated ORPC opnum for these
-operations or also synthesises them client-side. The R5 trigger conditions
-documented above ("subscription must exist") are derived from the
-.NET-reference compatibility server, not from a captured wire frame. Filed
-as F45 in `design/followups.md` to instrument those entrypoints in the next
-capture wave.
+A residual gap remained at the LMX-proxy boundary: capture 077 did not instrument `LmxProxy.dll!CLMXProxyServer.Suspend` / `.Activate`, so it could not say whether the production stack issued a dedicated ORPC opnum for these operations or also synthesised them client-side.
+
+This was filed as **F46** in `design/followups.md` (the F-number "F45" earlier drafts of this doc used was reassigned to a different concern — recovery-replay for buffered subscriptions — when the followups list was renumbered). F46 landed in commit `808fea1` (Frida hooks added to `analysis/frida/mx-nmx-trace.js`) and the live capture ran in commit `349e217` as F50. Verdict, per `docs/F50-suspend-activate-evidence.md`:
+
+- **Suspend** is server-side: emits NMX `PutRequest` with command `0x2D` ~140 ms after the LMX-proxy entry, body shape `2d 01 00 + correlation_id + 22 bytes` (same family as `0x1F` AdviseSupervisory).
+- **Activate** against a non-suspended item is client-side only — no wire traffic, returns Success synchronously.
+
+R5 in `design/70-risks-and-open-questions.md` is now settled. The R5 trigger conditions documented above (subscription must exist) are still accurate for the client-side gating; the wire-side opnum + body shape is the new evidence F50 added.
 
 ## Consolidated R2 / R5 status
 
@@ -293,11 +288,4 @@ capture wave.
   Future regressions are guarded by the new round-trip tests. Status moves
   from "P3 likely-not-a-real-risk" to "settled per option (b) with codec
   change landed under F44".
-- **R5 trigger conditions — observed.** From capture 077: `Suspend`
-  succeeds (returning `MxStatus.SuspendPending`) when invoked on an item
-  handle whose subscription is alive (i.e. immediately following a
-  successful `Advise`/`AdviseSupervisory`). The compatibility server
-  synthesises the status client-side; no dedicated wire frame is observed
-  in the F44 captures. The remaining unknown — does `LmxProxy.dll` itself
-  issue a Suspend/Activate ORPC method? — is filed under F45 with a Frida
-  hook plan.
+- **R5 trigger conditions — observed + wire shape settled.** From capture 077: `Suspend` succeeds (returning `MxStatus.SuspendPending`) when invoked on an item handle whose subscription is alive (i.e. immediately following a successful `Advise`/`AdviseSupervisory`). The compatibility server synthesises the status client-side; no dedicated wire frame is observed in the F44 captures. The remaining unknown — does `LmxProxy.dll` itself issue a Suspend/Activate ORPC method? — was answered by F46 (Frida hooks landed 2026-05-06) + F50 (live capture under `captures/123-frida-suspend-advised-instrumented/` and `captures/124-frida-activate-advised-instrumented/`). Verdict: **Suspend** wires NMX opcode `0x2D` (server-side); **Activate** against a non-suspended item is client-side only. R5 closed.
diff --git a/docs/M6-live-verification.md b/docs/M6-live-verification.md
index 1526acd..9fea8b7 100644
--- a/docs/M6-live-verification.md
+++ b/docs/M6-live-verification.md
@@ -157,4 +157,4 @@ cargo test -p mxaccess-compat --features live-windows-com `
 
 ## Open work
 
-- **F50** — residual Frida capture for Suspend/Activate (independent of F49).
+None. F49 sweep complete; F50 (residual Frida capture for Suspend/Activate) closed 2026-05-06 per `docs/F50-suspend-activate-evidence.md`.