scx_lavd: support large x86_64 systems (raise LAVD_CPU_ID_MAX to 8192)

[jkkm]

Two commits:

1. scx_lavd: bound per-cpdom cpumask scan loops by nr_cpu_ids
2. scx_lavd: raise LAVD_CPU_ID_MAX to 8192 to support large x86_64 systems

Problem

scx_lavd panics in Scheduler::init ("Num possible CPU IDs (N) exceeds
maximum of (512)") on any machine with more than 512 possible CPUs, so it
cannot run there at all. LAVD_CPU_ID_MAX sizes the CPU-id-indexed rodata
arrays (cpu_capacity, cpu_sibling, cpu_big, cpu_turbo, pco_table) and
the per-cpdom __cpumask bitmap.
Separately, the per-cpdom bitmap scan loops iterate the full
LAVD_CPU_ID_MAX/64 longs regardless of the actual CPU count, so raising the
cap would add wasted iterations on every system.

Fix

Commit 1 breaks out of each scan loop (collect_sys_stat,
plan_x_cpdom_migration helper, init path) once the long index is past
nr_cpu_ids. __cpumask bits are only set for CPU ids < nr_cpu_ids, so the
remaining longs are always zero. The loop keeps its compile-time
LAVD_CPU_ID_MAX/64 bound, so the __cpumask[i] access stays provably in range
for the verifier — the test is just an early exit. The scan now costs
ceil(nr_cpu_ids/64) iterations regardless of LAVD_CPU_ID_MAX.
Commit 2 raises LAVD_CPU_ID_MAX from 512 to 8192 (x86_64 MAXSMP).

Testing (NR_CPUS=1024 kernel, veristat)

• All programs verify; verifier complexity is unchanged by the bump (the
  scan loops are open-coded iterators, verified once regardless of bound).
• No runtime cost from the larger cap: commit 1 makes the loops scale with
  nr_cpu_ids, so on a 316-CPU host the scan runs 5 iterations whether the cap
  is 512 or 8192 (vs 128 for an un-bounded 8192 loop).
• Static cost of the bump: ~345 KB per scheduler instance (~225 KB rodata
  for the CPU-id-indexed arrays + ~120 KB for the per-cpdom __cpumask).

Note

8192 is the x86_64 maximum; architectures with a larger NR_CPUS may need a
higher value (or sizing the cap from the arch maximum).