vgsp-dual: cuda bridge queued work carries its owning mdev (G5 follow-on)

The host CUDA bridge is the GR fallback path when a forward request is
refused under the single-inflight slot (the expected steady state with
two guests). Its FIFO request and pending records dropped the owning
vgpu, so guest B's fallback job could be marshalled (VAs resolved, guest
memory read/written) through guest A's address space.

- cubb_req/cubb_pend gain the owning mdev; the launch stores it and it
  is part of the dedup identity.
- Only the owning guest's service pass marshals its job or drives its
  staged completion; a head/record whose mdev is gone is dropped instead
  of ever being dereferenced.
- One guest: head_owner is always the pumped vgpu, so behaviour is
  unchanged.

0 files changed, 0 insertions, 0 deletions