[cpu][windows]: harden the cpu-total computation added in #2125

Follow-up to #2125, which stopped deriving cpu-total from GetSystemTimes
and accumulates the per-processor counters instead.

- Fall back to GetSystemTimes for cpu-total when perfInfo() fails.
  perfInfo() relies on the undocumented NtQuerySystemInformation, so
  Times(false) would now fail outright where that call is unavailable,
  even though the public API would still work. The processor-group
  problem #2125 fixes does not apply to the fallback, which is only
  taken when the group-aware query is unusable in the first place.
- Resolve every proc with Find before calling it in perfInfo().
  LazyProc.Call panics when it cannot resolve the proc, so on a host
  where NtQuerySystemInformation is missing the fallback above was
  unreachable: the process would go down instead. Only the Ex variant
  was probed before.
- Return an error instead of an all-zero cpu-total when perfInfo()
  reports no processors.
- Drop the accumulation of DpcTime and InterruptCount: TimesStat has no
  field for either, so the sums were never used. The struct fields stay,
  they are needed for the buffer layout passed to the Windows API.
- Restore the note from #2110 explaining why the tick counts are summed
  as integers and converted to float64 only once.
- Add TestTimesTotalMatchesPerCPUSum, asserting that cpu-total is the
  field-wise sum of the per-CPU stats. Its tolerance scales with the
  wall clock time actually measured between the two Times calls, so a
  descheduled test goroutine on a busy CI host does not make it flaky.
- Add TestSystemTimes, covering the fallback directly. TimesWithContext
  only reaches it when perfInfo() fails, so it would otherwise ship
  untested.
- Fix a stale comment in the psutil comparison test: Windows no longer
  derives cpu-total from GetSystemTimes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>