vmbus: vmbus_msghc_wait_result blocks uninterruptibly with no timeout - a silent or malicious Hyper-V host permanently wedges device attach at boot (and later wedges vmbus_msghc_ctx_destroy/kldunload too)

Summary

wait_result spins in an uninterruptible timeout-less tsleep; vmbus_init calls it from attach for every offered protocol version - a host that never injects VERSION_RESP leaves boot asleep forever with zero console output. The same wait is inherited by get1, so later teardown also hangs: sticky wedge, no recovery short of hard reset. Availability twin of DF-1668 under the malicious-host model. Bounded-wait+ECOMM fix.