Fix attempt 1 (dedicated lwkt_token taken by BOTH the netisr walkers and
the mutators) - REJECTED, panics the patched kernel itself:

  LWKT_RELTOKEN ASSERTION td 0xfffff8008babf000 tok 0xffffffff810dd960 ...
  REF CONTENT: tok=0xffffffff810fe340 count=0000000000000003 owner=0xfffff8008babf000
  lwkt_reltoken: release wants mp_token and got encap_token
  panic: lwkt_reltoken: illegal release
  Trace: lwkt_reltoken() x2 <- transport_processing_oncpu <- ip_input
         <- netmsg_service_loop

Lesson: DF netisr transport processing (transport_processing_oncpu, hence
encap4_input) already runs holding mp_token; introducing a second token
inside that context and releasing it there violates LWKT tokref ordering.
Fix attempt 2 takes mp_token only in the mutators (encap_attach,
encap_attach_func, encap_detach) - the walkers already hold it implicitly -
which serializes mutation against the walk without nesting a new token
inside netisr. (Captured from the guest serial console before the reset
that followed; original console text lost on reset - these are the exact
lines as printed at boot.log:429-438, kernel #1 built 2026-09-12 13:03.)