DF-4895 — complete_raid5_write() launches RAID-5 second-phase I/O via
vn_strategy(drive->vp) with no validity guarantee on the vnode

ROOT CAUSE (sys/dev/raid/vinum/vinuminterrupt.c)
  * :427  vn_strategy(drive->vp, &rqe->b.b_bio1);        (second-phase data write)
  * :464  vn_strategy(drive->vp, &rqe->b.b_bio1);        (parity write)
  The first phase launches the very same requests via
  dev_dstrategy(rqe->b.b_bio1.bio_driver_info, ...) with the *cdev*
  (vinumrequest.c:436, bio_driver_info = DRIVE[].dev set in
  build_rq_buffer vinumrequest.c:828 and re-set at vinuminterrupt.c:404/440).
  The cdev stays valid across vinum's drive teardown; the *vnode* does not:
  set_drive_state(down) queues daemonrq_closedrive (vinumstate.c:87-89) and
  the vinum daemon runs close_locked_drive() -> vn_close(drive->vp);
  drive->vp = NULL (vinumio.c:225-227) with no synchronization against the
  request completion path.  Any group write that was built while the drive
  was up (or whose states were administratively restored) then faults:
  vn_strategy() dereferences vp immediately (vfs_bio.c:3368/3375).

  Teardown can be triggered by:
  - complete_rqe()'s own ENXIO error branch (vinuminterrupt.c:129-139)
    force-downs the drive and then, IN THE SAME CALL, continues into
    complete_raid5_write() which launches more vn_strategy()s (race vs
    the daemon's vn_close -> closed-vnode use, or NULL deref);
  - administrative `vinum stop -f <drive>` racing in-flight group writes;
  - state-poke recovery (`vinum setstate -f up`) after a stop, which
    restores drive/sd/plex states without re-opening vp.

GUEST REPRODUCTION (deterministic, no fault injection needed)
  1. sh setup_vinum.sh   (2 md drives, 3-sd RAID-5 "rv", 2 sds on d2)
  2. vinum stop -f d2    (real set_drive_state down: daemon vn_close's vp;
                          sds cascade to crashed)
  3. sleep 3
  4. vinum setstate -f up d2; vinum setstate -f up rv.p0.s0 rv.p0.s1 \
        rv.p0.s2 rv.p0 rv     (state pokes; vp stays NULL)
  5. dd of=/dev/vinum/vol/rv bs=32768 seek=5 count=1   (single group write)

  Expected (unpatched): first-phase reads complete via the still-valid
  cdev, then complete_raid5_write() calls vn_strategy(NULL):
    Fatal trap 12: page fault while in kernel mode
    fault virtual address = 0x5c
    Stopped at vn_strategy+0x38: testb $0x40,0x5c(%r13)
  (vfs_bio.c:3375  (vp->v_flag & VKVABIO) == 0 — NULL vp deref.)

  Observed on guest DragonFly 6.5-DEVELOPMENT (x86_64), 2026-09-24: see
  panic.txt (full serial-console capture), run.log (session transcript).

IMPACT
  Privileged local kernel DoS (guaranteed panic) once vp is torn down or
  raced; the mid-flight variant (vn_strategy on a vnode concurrently
  vn_close'd by the daemon) is a vnode use-after-close -> potential
  memory corruption.  Trigger requires vinum administrative control
  (root) or a genuine component ENXIO failure, hence severity Medium.

FIX (fix.diff)
  Launch the second phase exactly like the first phase — via the cdev the
  code already stores in bio_driver_info at :404/:440:
    -		    vn_strategy(drive->vp, &rqe->b.b_bio1);
    +		    dev_dstrategy(rqe->b.b_bio1.bio_driver_info, &rqe->b.b_bio1);
  (both sites).  dev_dstrategy() on DRIVE[].dev is the proven first-phase
  mechanism and is unaffected by drive->vp teardown.
  NOTE: sdio() in vinumrequest.c:980 uses the same vn_strategy(drive->vp)
  pattern and needs the same treatment (out of scope for this diff).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.