Fix fence completion race in virtio-gpu worker

[aford173]

Summary

Fix an out-of-order fence completion race that causes the guest to hang intermittently during heavy GPU
rendering through vDRM/virtio-gpu.

When virglrenderer immediately retires fence N+1 (no GPU work) before the timeline thread signals fence N,
the unconditional insert() in the fence handler overwrites completed_fences[ring] from N+1 back to N.
The worker's process_fence() then sees N+1 > N and adds fence N+1 to the pending list, where it stays
forever — the retirement callback already fired and won't fire again.

The fix uses a max check so only strictly higher fence_ids update the map.

Discovered while bringing up vDRM GPU passthrough on an MT8196 Chromebook (Mali-G725 / Panthor). The hang
was reproducible with glmark2 after ~100K-1.5M frames during multi-pass rendering scenes (desktop blur,
terrain, refract). Simple apps like glxgears ran indefinitely.

Test plan

• glmark2 full benchmark completes all 33 scenes without hanging (previously hung intermittently at heavy
  multi-pass scenes)
• glxgears runs indefinitely (unchanged)
• Score: 674 (MT8196/Mali-G725 via vDRM)

[slp]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the virtio_gpu module to correctly handle out-of-order fence completions. Specifically, it updates the logic for completed_fences to ensure that the highest fence_id is always retained for each ring, preventing a lower fence_id from overwriting a higher one. The reviewer suggests a more concise implementation for this max logic using u64::max.

[gemini-code-assist]

This logic can be expressed more concisely by using u64::max.

            *entry = (*entry).max(completed_fence.fence_id);

[aford173]

@slp - I have updated this accordingly.

[mz-pdm]

Makes sense to me.
The CI can be fixed by rebasing on main, I think.

[slp]

Let's merge #608 instead. It'll be cherry-picked into stable.