Claude review: vfio/pci: Clean up BAR zap and revocation

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

Consolidates `vfio_pci_zap_bars()` + `vfio_pci_dma_buf_move()` into `vfio_pci_zap_revoke_bars()`. Clean refactoring.

**`vfio_pci_ioctl_reset` change**: The lock acquisition changes from `vfio_pci_zap_and_down_write_memory_lock` (which did lock+zap atomically) to separate `down_write` + `vfio_pci_zap_revoke_bars`:
```c
-	vfio_pci_zap_and_down_write_memory_lock(vdev);
+	down_write(&vdev->memory_lock);
...
-	vfio_pci_dma_buf_move(vdev, true);
+	vfio_pci_zap_revoke_bars(vdev);
```
This moves the zap/revoke to *after* the D0 power transition, which the changelog notes. This is intentional per the v2 notes but is a behavioral change worth PCI maintainer attention.

**`bar_needs_zap` flag**: Set in nvgrace-gpu but never cleared. This means once any nvgrace-gpu BAR is mmap'd, the zap path will always fire even after that BAR is unmapped. The FIXME acknowledges this, and the overhead is minimal (an extra `unmap_mapping_range` on an empty range), so this is acceptable as an interim solution.

---
Generated by Claude Code Patch Reviewer