Input validation for `num_sms` parameter in `Buffer` initialization, specifically against the physical SM count of 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

```text
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 determinis...