Reverts the data-location half of #39 (capabilities-as-variable):
structured/relational graph data (entities/graph) moves back to a
dedicated top-level "capabilities" key instead of a magic-named
"variables" entry.

Why: glTF Interactivity's own "variables" array holds only scalar/vector
value-socket-typed fluent state (bool/float/int/ref/...) — real glTF
extensions needing structured, non-scalar, extension-specific data (e.g.
KHR_lights_punctual's "/extensions/KHR_lights_punctual/lights") get their
own namespaced property at the extension root, never crammed into the
generic variable list. KHR_interactivity itself follows this: its own
extension object has four separate arrays (types, events, variables,
nodes), not one array wearing multiple hats. A magic-named "variables"
entry is also a real Lisp-1-style hazard: a domain author who names an
unrelated variable "capabilities" would silently get wrong ReBAC
graph-building behavior with no error, instead of a namespace boundary
signaling the name is reserved.

The other half of #39 — no compiled sugar for per-action capability
requirements — is unaffected and stays: a domain author writes the
{"eval": {"type": "rebac/check", ...}} guard step directly into the
action's own body, the same mechanism every other action precondition
uses. That simplification was independently justified (the sugar was
just re-deriving what a hand-written check clause already does) and
isn't part of the data-location question this reverts.

"capabilities" restored to the loader's top-level key whitelist.