Stage K-6: riscv64 vblk_io timeouts root-caused and fixed -- time bound, exact used-ring accounting (FABRIC-3.10.8 §4.7)

- Investigation (riscv64): completions are slow, not lost -- up to 15 ms,
  while the ~1M-iteration bound was ~14 ms of guest time. Each timeout
  left the request in the device while the driver forgot it; the next
  request took its used entry as its own and returned before its own I/O
  finished, and so did every later one (394 in one boot), rewriting
  descriptors the device was still reading.
- Fix: VBLK_TIMEOUT_MS (2 s) on the raw hardware counter; each request
  waits for exactly one more used entry; a timed-out request stays
  outstanding and its completion is drained before anything is reused,
  or the next request is refused untouched. Counters for timeouts, late
  drains and busy refusals.
- After the fix, all three ISAs: 0 timeouts, 0 unaccounted completions
  over 1,912 I/Os; riscv64 slowest completion 7.7 ms (was 15.1).
- Standard sequence on amd64/aarch64/riscv64: hash, G, ledger unchanged;
  0 timeouts in the riscv64 log.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

include/starkernel/virtio_blk.h

@@ -54,4 +54,11 @@
  */
 int virtio_blk_find_artemis(blkio_dev_t *dev_out);
 
+/* FABRIC-3.10.8 K-6 counters: requests that timed out (left outstanding),
+ * late completions drained before a later request, and requests refused
+ * because an earlier one was still in the device. */
+uint64_t virtio_blk_timeouts(void);
+uint64_t virtio_blk_late_consumed(void);
+uint64_t virtio_blk_refused_busy(void);
+
 #endif /* STARKERNEL_VIRTIO_BLK_H */