Record minimum required kernels version in build metadata (based on features used) #800

Problem

A kernel build can rely on metadata/features that only newer versions of the kernels library understand (e.g. kernel-depends / kernel-to-kernel dependencies, new backend descriptors, new digest or provenance fields). Today metadata.json — e.g. flash-attn2 v3 — has no notion of which kernels version is needed to consume it:

{
  "name": "flash-attn2",
  "version": 3,
  "python-depends": [],
  "kernel-depends": [],
  "backend": { "type": "cuda", "archs": ["8.0", "9.0"] },
  ...
}

So a user on an older kernels release that loads such a build either silently ignores the fields it doesn't know about or fails with a confusing error, instead of being told "upgrade kernels to >= X".

Proposal

1. Have the builder emit a minimum-required-kernels version in metadata.json, e.g. "requires-kernels": ">=0.12", computed from the features actually used by the build (kernel deps present → bump the floor; only basic fields → keep the floor low so old clients keep working).
2. In kernels, check that field at load time and raise a clear, actionable error when the installed version is too old:

   Kernel 'kernels-community/flash-attn2' (revision v3) requires kernels >= 0.12, but 0.9.1 is installed. Please upgrade: pip install -U kernels
   

3. Treat a missing field as "no constraint" for backwards compatibility with already-published builds.

This complements #744 (suggesting a newer kernel version when no compatible variant exists) — here the mismatch is on the library side rather than the build-variant side.

Follow-ups discussed

• Verify the kernel-to-kernel dependency feature doesn't break the Transformers kernels tests (check with Anton).
• The emitting side likely lives in kernel-builder; the consuming/validation side in kernels. Feel free to split this issue if the builder change is tracked separately.

Requested by Sayak Paul - Slack thread - Agent trace