oci: correct sub-core CPU quota mapping and add cpuset to cpu_cores affinity

[congwang-mk]

Summary

Improves OCI CPU resource mapping in sandlock-oci, correcting one mapping and adding a missing one. Two focused commits.

1. Map only enforceable sub-core CPU quota to max_cpu throttle

cpu.quota/cpu.period was mapped with ((quota/period)*100).min(100.0). The .min(100.0) silently discarded any >= 1-core request, and combined with core's if cpu_pct < 100 guard a >= 1-core quota became max_cpu = 100, which core reads as no limit at all.

• Sub-core (quota < period): map to 1-99%, flooring to 1 so a tiny fraction isn't truncated to 0 (and silently dropped to "no limit").
• >= 1 core: left unmapped. max_cpu is a coarse global SIGSTOP/SIGCONT wall-clock duty cycle, not a bandwidth controller, and a multi-core allowance can't be expressed as a 1-100 value. A multi-core cap belongs on affinity, not this throttle.

2. Map cpu.cpus cpuset to cpu_cores affinity

OCI cpu.cpus (e.g. "0-3,7") was dropped entirely. It maps exactly to core's cpu_cores (sched_setaffinity), so this is genuine, non-approximate multi-core enforcement, and it is what the field means.

• New parse_cpuset helper: comma-separated indices and inclusive ranges, sorted and de-duplicated; malformed/empty input drops to None (no partial pinning).
• New OciPolicy.cpu_cores field, wired through from_spec and to_sandbox.

Testing

9 new unit tests (CPU quota cases + cpuset parsing + end-to-end mapping). Full sandlock-oci suite: 37 passed, clean build.

Out of scope

A pure multi-core quota with no cpu.cpus present (the approximate pin-to-N-cores hack) is intentionally not implemented, its bandwidth-vs-pinning tradeoff is a separate design decision.

[congwang-mk]

@sachin2605 Please take a look. Thanks!