L2: record the pgrep -f tap141i0 hazard - it kills the guest, not just tcpdump

QEMU's command line contains ifname=tap141i0, so pgrep -f on the tap name matches
the VM alongside the capture. Stopping the tcpdump that way SIGTERM'd VM141.
Nothing was lost (all artefacts were already off the guest and it restarted with
a clean volume) but it is a plug-pull on an exclusively-held guest. Use
pgrep -x tcpdump.

findings/subsystems/multiplayer-combat.md

@@ -264,6 +264,15 @@ What the clone carried over correctly and did **not** need fixing: the game at `
 — **the Windows Defender Firewall rule for the game**, so the "has blocked some features of this
 app" prompt W2 had to click through on VM140 never appeared here.
 
+**One hazard found the hard way, and it will bite the next lane too: `pgrep -f tap141i0` matches
+QEMU itself.** Stopping the capture with `pgrep -f "tap141i0" | xargs kill` on spicy killed the
+guest — QEMU's command line contains `...,ifname=tap141i0,...`, so the VM's own process matched
+alongside `tcpdump`, and the journal records `kvm: terminating on signal 15`. It cost nothing here
+because every artefact was already off the guest, and the guest restarted clean (`fsutil dirty query
+C:` → not dirty), but it is a plug-pull on someone's exclusive guest. **Kill the capture with
+`pgrep -x tcpdump`, never with `-f` on the tap name.** The same trap catches `pkill -f "tcpdump -i
+tap141i0"` run over SSH, where the pattern also matches the remote shell that is running it.
+
 What it carried over that **had** to be fixed:
 
 - **`shim.cfg` was lane W3's `hooks=trace`.** Any lane that wants the shipped game must overwrite it;