# DF-4541 — hptmv `AS_INITIALIZE_START` queues the wrong DPC flag; initialize never runs, ioctl stalls 80 s and reports success

## What

`hpt_set_array_state()` case `AS_INITIALIZE_START`
(sys/dev/raid/hptmv/ioctl.c:572-591) queues the rebuild DPC with the
`VERIFY` flag:

```c
580:  hpt_queue_dpc((HPT_DPC)hpt_rebuild_data_block, pAdapter, pVDevice, VERIFY);
```

Compare `AS_VERIFY_START` (ioctl.c:540) which correctly queues `VERIFY`,
and `HPT_IOCTL_CREATE_ARRAY` with `CAF_CREATE_R5_ZERO_INIT`
(ioctl.c:392) which correctly queues `INITIALIZE`.  This is a copy-paste
bug: `hpt_rebuild_data_block(flags==VERIFY)` only ever sets
`rf_verifying` (ioctl.c:729-736), never `rf_initializing`
(ioctl.c:720-727).

## Consequence

1. `while (!pVDevice->u.array.rf_initializing)` (ioctl.c:583-589) can
   never become true: the calling thread polls with `tsleep(..., 1)`
   until `timeout >= hz*80` — an ~80-second stall of the sysctl-write
   thread per call.
2. After the timeout the function falls through and `return 0`
   (ioctl.c:616) — the management tool is told the array
   initialization *started* when nothing happened.  The event queue
   gets `ET_VERIFY_STARTED` instead of `ET_INITIALIZE_STARTED`.
3. Security-relevant residue: "initialize array" is the data-hygiene
   feature that is supposed to write the array; a silent no-op defeats
   the user's wipe expectation when arrays are re-purposed.

The same silent-timeout-returns-success protocol exists in every wait
loop of this function (ioctl.c:494-500, 519-525, 543-549, 562-568,
602-608) and in `Kernel_DeviceIoControl`'s ADD_DISK_TO_ARRAY post-
processing (ioctl.c:430-436), but only the INITIALIZE case is
*guaranteed* to hit it on every call.

## Reachability

The hptmv ioctl channel is the writable sysctl `dev.hptmv.status`
(hptproc.c:614-617). Sysctl writes require root; the array must exist
on real HighPoint hardware.  Not testable on the audit QEMU guest
(no HighPoint HBA → `gIal_Adapter` NULL, see DF-1853 for that path).

## Trigger

`hptinit.c <array-id>` — builds the `HPT_IOCTL_PARAM` packet for
`HPT_IOCTL_SET_ARRAY_STATE` (0xFF0F) with `state = AS_INITIALIZE_START`
(7) and writes it to `dev.hptmv.status`.

Expected on vulnerable driver: returns success after ~80 s; dmesg shows
`hptmv: Verifying started.` rather than `Initializing started.`

## Fix

Queue `INITIALIZE`, and make the wait loops report failure on timeout.