Validate optimization hint values against Tile IR constraints

[elibol]

Optimization hints are forwarded to the backend without value validation. The Tile IR spec constrains each hint, but cutile only checks that the value is an integer, so an out of range value becomes a late tileiras verifier error instead of an early cutile error with a source location.

Constraints per the Tile IR attribute definitions:

Hint	Constraint
num_cta_in_cga	power of 2 in [1, 16]
occupancy	integer in [1, 32]
num_worker_warps_per_cta	power of 2 in [1, 32]
latency (op level)	integer in [1, 10]

We should validate at both entry points: the optimization_hints macro path (SMHints setters) and the runtime CompileOptions builder. Each should reject out of range values with an error that states the valid range. The book and host-api reference should document the ranges next to each hint.

Came up in #206, where the forwarding test used values the backend verifier rejects. Version compatibility is already enforced (the 13.3 gate for num_worker_warps_per_cta); this issue is about value constraints only.

[elibol]

Constraint behavior, confirmed against the Tile IR implementation (plus the empirical report on #206): hint value checking in the backend is warning only (behind -Wunsupported-hints) and off by default. For out of range values the backend silently ignores the hint, substitutes its default, or clamps. For num_worker_warps_per_cta specifically: a non power of 2 in range is ignored (default 4 used), values below 1 get the default, powers of 2 above 32 are clamped to 32, and non powers of 2 above 32 are ignored. The only hard error is the physical warps per CTA limit, which is not a hint check.

So without cutile side validation a bad hint silently produces a different kernel configuration than requested, with no diagnostic anywhere. Validation here is load bearing, not a nicety.

Two scope additions:

1. Consider forwarding -Wunsupported-hints to tileiras in debug mode (e.g. when CUTILE_JIT_LOG is set) so backend hint diagnostics surface during development.
2. Hint checking must stay entirely on our side; do not assume the backend will ever reject a value.