The old "suricata in IPS mode won't stop cleanly, GUI says stopped but the process is still running, needs a manual kill" behavior is well known from the netmap days (opnsense/core#3868 (https://github.com/opnsense/core/issues/3868), #4257 (https://github.com/opnsense/core/issues/4257), #710 (https://github.com/opnsense/core/issues/710); and here on the forum, "Hanging at reboot: stopping suricata" (https://forum.opnsense.org/index.php?topic=26275.0) back on 21.7). I ran into what looks like the same class of thing in the newer Divert mode, and in my case it hung a reboot badly enough to be worth flagging. I put the reboot details in opnsense/core#10567 (https://github.com/opnsense/core/issues/10567).
Setup here: 27.1.a devel, Divert (IPS), 12 divert threads (-d 8000 x12), a single narrow divert-to flow that sees very little traffic. On stop, suricata caught SIGTERM (procstat -i: TERM --C) and started shutting down but never exited. rc.d/suricata stop then sat in pwait for over 90 minutes. procstat showed the divert worker threads parked in sbwait/select on the divert socket, plus a few in umtx waits. My best guess is the workers are blocked reading the divert socket with nothing to wake them on this quiet flow, so the shutdown never completes, but it's only a guess.
Is the divert-mode stop hang tracked separately from the old netmap lockups, or is it the same known "kill it and move on" behavior? I can characterize it further if that helps (traffic during the stop, thread count, PCAP vs divert). Otherwise I'll keep a kill -9 in my stop path and leave it there.