Update docs/draft/concepts/clusterobjectsets.md

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: perdasilva

docs/draft/concepts/clusterobjectsets.md

@@ -137,12 +137,12 @@ Each object in a phase can be stored in one of two ways (exactly one must be set
 :   The full Kubernetes manifest is embedded inline in the ClusterObjectSet. Simple and self-contained, but contributes to the overall size of the ClusterObjectSet resource in etcd.
 
 `ref`
-:   A reference to a Secret that holds the serialized object manifest. The `ref` specifies the Secret name, namespace, and data key containing the JSON-encoded manifest. This allows ClusterObjectSets to manage bundles that would otherwise exceed etcd's 1.5 MiB object size limit.
+:   A reference to a Secret that holds the serialized object manifest. The `ref` specifies the Secret name, namespace, and data key containing either a JSON-encoded manifest or gzip-compressed JSON bytes. This allows ClusterObjectSets to manage bundles that would otherwise exceed etcd's 1.5 MiB object size limit.
 
 When operator-controller creates ClusterObjectSets for ClusterExtensions, it automatically externalizes objects into immutable Secrets:
 
 - Secrets are packed up to 900 KiB each, leaving headroom below the etcd limit
-- Objects larger than 900 KiB are gzip-compressed before storage
+- Objects larger than 900 KiB are gzip-compressed before storage (ref resolution auto-detects and transparently decompresses gzip-compressed values so consumers see the original JSON manifest)
 - Secrets use content-addressable naming for deduplication
 
 For a detailed design discussion, see [Large Bundle Support](../../concepts/large-bundle-support.md).