feat(tcmu): support multi-vCPU backends with Photon v0.9

[liulanzheng]

Dispatch TCMU commands across a shared Photon WorkPool and let each vCPU publish its own responses, make compression batch state request-local, allow the file cache in multi-vCPU mode, and add a benchmark that compares the backend against the single-vCPU implementation on the same runner.

Commands go onto the pool's own task ring, so the device dispatcher never leaves its vCPU and keeps draining its mailbox: WorkPool spreads a batch over whichever vCPUs are free, and its RingChannel pays for a wakeup only when a worker is parked, so a saturated pool dispatches with plain atomic pushes. Each task just spawns the handler thread and returns, because the pool runs tasks inline on its own loop. Completions are published in place under a per-device spinlock with the uio notification coalesced by a counter, instead of being forwarded to the device's home vCPU one wakeup per command. libtcmu keeps the reader's cursor (dev->cmd_tail) separate from the response cursor (mb->cmd_tail) and the kernel matches responses by cmd_id, so completions only have to be mutually exclusive and must never run ahead of the reader; the in-flight count is released last because device teardown waits on it before freeing the device.

Fan-out is load adaptive: while a device holds no more than two in-flight commands per pool vCPU there is not enough concurrency to pay for waking another vCPU and moving the command's cache lines to it, so the batch runs where it was read, exactly as a single-vCPU backend would run it.

Measured against the single-vCPU baseline on a GitHub runner (4 KiB random reads, libaio, O_DIRECT, Debug build, workpoolSize=8): qd1-j1 0.99x, qd4-j2 1.00x, qd16-j4 1.68-2.59x, qd32-j8 3.33-5.51x, with qd32-j8 mean latency down from 6.3-11.3 ms to 1.9-2.0 ms. The spread comes from the baseline, whose single vCPU is far more sensitive to runner contention than the pool is. The comparison table is published as a check-run annotation because job logs and artifacts require repository authentication.

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Please check the following list:

• Does the affected code have corresponding tests, e.g. unit test, E2E test?
• Does this change require a documentation update?
• Does this introduce breaking changes that would require an announcement or bumping the major version?
• Do all new files have an appropriate license header?