Problem

The generic vhost-user frontend advertises a fixed feature set to the guest:

VIRTIO_F_VERSION_1 | VIRTIO_RING_F_EVENT_IDX | VHOST_USER_F_PROTOCOL_FEATURES

Feature negotiation then intersects that with the backend's features
(acked = avail & backend), so every device-specific bit the backend offers
(virtio spec bits 0..23) is masked out before the guest ever sees it. The guest's
negotiated features are correctly forwarded to the backend at activation, so the
gap is purely on the advertise side.

Impact

• A read-only block backend loses VIRTIO_BLK_F_RO, so the guest mounts it
  read-write.
• A virtio-net backend loses checksum offload, mergeable RX buffers, multi-queue,
  MAC and the rest, which makes it close to unusable.

Why it is not a one-line mask

Blindly advertising bits 0..23 lets the guest negotiate features that assume
backend-driven queue or config semantics inconsistent with the frontend's fixed
num_queues (for example block VIRTIO_BLK_F_MQ), which breaks activation and
hangs the guest. A correct fix has to reconcile the advertised feature set with
the frontend's queue count and config space, and pick a transport-bit policy the
frontend can actually honour (split rings only, no vIOMMU, and so on).

Scope

Deferred from the takeover of firecracker-microvm#5773. The
test_vhost_user_generic_block read-only assertion is marked xfail until this is
resolved. Needs a design decision on the correct feature-masking policy, ideally
with maintainer input on the upstream PR.