Intentionally inert: everything here happens at build time, in build
tooling that statically discovers this call -- never at runtime, in every
process that imports the capability file, which is exactly what this
split (mirroring env-cap's documentEnv) exists to avoid. Never throws,
regardless of malformed input, and a documentData call is never itself
evidence that an executable capability exists -- static analysis (build)
inspects only real buildData/createData calls.
Adds documentation/operational metadata to the same capability graph a
buildData/createDatacall describes, without introducing runtime behavior.configshould be the exact same schema object passed tocreateData/buildData(typically a separately-declaredconstreused by both calls, the same way afieldsidentifier is already shared) -- passing the same object is what letsdocs'getters/mutators/subscriptionskeys be checked against the schema's real operation names, not just itsfields. A{fields}-only config (no operations) still works for a capability with none to document.