[Bug] num_sms is not validated against the current CUDA device

Problem

Buffer(num_sms=...) accepts any positive integer and stores it as the grid
size for MoonEP's cooperative communication kernels. It does not check the
value against the current CUDA device.

The parameter is presented as an SM budget, so accepting a value greater than
the device's physical SM count is surprising and defers the failure to
kernel-specific compilation or launch behavior. That produces a less useful
error than an API precondition failure.

This is not a claim that every cooperative grid larger than the physical SM
count must deadlock. CUDA's legal cooperative grid size depends on active
blocks per SM as well as the SM count. The proposed bound is a conservative
MoonEP API contract for a parameter that represents the number of SMs devoted
to communication.

Current flow

Buffer(num_sms)
      |
      +--> positivity assertion
      |
      +--> context allocation and kernel compilation
      |
      `--> cooperative grids use num_sms CTAs

Expected behavior

• Reject booleans and non-integer values with TypeError.
• Reject zero and negative values with ValueError.
• Reject explicit values greater than the current device's physical SM count
  before allocating the communication context.
• Resolve None to min(32, device_sm_count), preserving the existing default
  on larger GPUs while keeping default construction usable on smaller devices.
• Accept the exact device SM count.

Why validate in the API?

The check is deterministic, inexpensive, and independent of a particular
compiled kernel's occupancy. It gives callers a clear configuration error
before VMM allocation or cooperative-kernel compilation begins.

Start at the Buffer(num_sms) entry point and trace the existing positivity assertion through device context allocation and kernel compilation. Implement the stated type, range, device-SM bound, and None-default behavior, ensuring invalid explicit values fail before allocation or compilation.