ci: remove the duplicate KVM counting-LAPIC precheck #286

Summary

After #285, MSHV and WHP no longer need a separate smp-lapic execution because their CPU contracts hide TSC-deadline and the ordinary smp scenario already exercises the counting LAPIC.

KVM still runs the same counting-LAPIC correctness scenario twice in CI:

1. The default nvx-microvm-tests-kvm suite runs smp-lapic for 1, 2, 4, and 8 vCPUs.
2. .github/actions/run-benchmark/action.yml runs another smp-lapic 1/2/4/8-vCPU gate before KVM performance acceptance.

The second path was added to protect benchmark collection from a broken counting LAPIC, but the required status, release, and performance-persistence paths already include the KVM correctness job. Re-evaluate that wiring and remove the duplicate execution without weakening the correctness gate.

Proposed outcome

• Remove the dedicated Check KVM counting-LAPIC timers step from the benchmark action.
• Retain smp-lapic as an explicit scenario and in the default KVM microVM correctness suite.
• Make the workflow dependency explicit wherever benchmark data could otherwise be accepted or persisted before KVM correctness is known.
• Keep platform benchmarks parallel with correctness tests unless serialization is required for correctness.

Acceptance criteria

• Document which jobs consume, gate, publish, or persist KVM benchmark results.
• Prove that a failed nvx-microvm-tests-kvm job prevents the required status, development release, and performance-history persistence from succeeding.
• Remove the duplicate pre-benchmark execution and its lapic-correctness output directory.
• Update doc/benchmarks.md and any affected workflow tests or documentation.
• Compare the KVM platform-job duration before and after the removal.
• Preserve explicit local use of test-microvm --scenario smp-lapic.

Non-goals

• Do not remove the smp-lapic scenario itself.
• Do not remove ordinary MSHV/WHP SMP coverage.
• Do not weaken the restore TSC-instability guard, host invariant-TSC validation, or snapshot clock contract.

Depends on #285 and its OpenVMM dependency nanvix/openvmm#105.