DF-2661 baseline run transcript (kernel A = stock + inject.diff, guest #1)

Host command:
  dfbsd-qemu/vm.sh run_root 'sh /root/df2661/trigger_df2661.sh 5'

The trigger (v3) per round: clone golden.img -> work.img, vnconfig -c
(no -T), mount_hammer2, `ls dir` (warm path walk only), arm
vfs.hammer2.df2661_fail_inode_read=1000000, launch 8 concurrent
`while :; do cat /mnt/h2661/dir/f$i; done` loops (8 distinct cold inodes,
one 64KB DIO window), sleep 15, kill loops, disarm, umount.

Observed: the ssh session produced no further output and the host-side
command timed out after 300s (guest wedged).  Serial console
(dfbsd-qemu/boot.log, copied to panic.txt / panic_full.txt) shows the
mount sequence of the round, then two CPUs printing simultaneously:

  hammer2_chain_load_data: I/O error <data_off>: 5     (chain.c:1001, CPU1)
  panic: assertion "dio->bp == NULL" failed in _hammer2_io_getblk
         at /usr/src/sys/vfs/hammer2/hammer2_io.c:264   (CPU2)

(264 = stock line 254 + 10 lines added by inject.diff; line 254 is
KKASSERT(dio->bp == NULL) executed right after acquiring DIO_INPROG.)

Trace:
  _hammer2_io_getblk() at _hammer2_io_getblk+0x63e
  _hammer2_io_getblk() at _hammer2_io_getblk+0x63e
  _hammer2_io_bread() at _hammer2_io_bread+0x17
  hammer2_chain_load_data() at hammer2_chain_load_data+0x2a5
  hammer2_chain_lock() at hammer2_chain_lock+0xde
  hammer2_inode_chain() at hammer2_inode_chain+0xbe
  Debugger("panic") ... db>

vm.sh status => down (ddb).  Guest afterwards reset with-src for the fix
build (buildA.log lost to that reset; the procedure is recorded in
build.sh and is byte-identical to the kernel A build minus fix_b.diff).