fix toc, fix spelling

Signed-off-by: lauralorenz <[email protected]>

Author: lauralorenz

keps/sig-multicluster/2149-clusterid/README.md

@@ -396,7 +396,7 @@ Implementers are free to add additional properties as they see fit, so long as t
 
 #### Note: On ClusterProperty.value max length validation
 
-Prior Kubernetes API constructs in core k/k containing arbitrary string values, such as annotations, are limited by a byte length. The CRD system exposes two built-in (as in, non-webhook) methods for expressing validation rules against CRDs: `CustomResourceValidation`, also known as structural schema, via OpenAPIv3 schema validation (as of Kubernetes version [1.14.7](https://relnotes.k8s.io/?areas=custom-resources&releaseVersions=1.14.7)), and CEL, also known as the `x-kubernetes-validations` extension (as of Kubernetes version [1.25](https://relnotes.k8s.io/?markdown=CEL&areas=custom-resources&releaseVersions=1.23.0)). Both systems define strings as Unicode code points, so any validation for maxLength will be based on number of code points, NOT on input byte count.  As a result, this specification can only express the limits on `ClusterProperty.value` length in terms of Unicode code points, regardless of which of these two validation methods are used (and, to maximize Kubernetes version compatability, using structural schema over CEL is advised). Note that this may not be the same as number of percieved characters (for example, flag emojis such as "🇺🇸" appear as 1 character but take up 2 code points) nor the number of bytes used to represent it in a given encoding (that same emoji uses 8 and 10 bytes in UTF-8 and UTF-16, respectively).
+Prior Kubernetes API constructs in core k/k containing arbitrary string values, such as annotations, are limited by a byte length. The CRD system exposes two built-in (as in, non-webhook) methods for expressing validation rules against CRDs: `CustomResourceValidation`, also known as structural schema, via OpenAPIv3 schema validation (as of Kubernetes version [1.14.7](https://relnotes.k8s.io/?areas=custom-resources&releaseVersions=1.14.7)), and CEL, also known as the `x-kubernetes-validations` extension (as of Kubernetes version [1.25](https://relnotes.k8s.io/?markdown=CEL&areas=custom-resources&releaseVersions=1.23.0)). Both systems define strings as Unicode code points, so any validation for maxLength will be based on number of code points, NOT on input byte count.  As a result, this specification can only express the limits on `ClusterProperty.value` length in terms of Unicode code points, regardless of which of these two validation methods are used (and, to maximize Kubernetes version compatibility, using structural schema over CEL is advised). Note that this may not be the same as number of perceived characters (for example, flag emojis such as "🇺🇸" appear as 1 character but take up 2 code points) nor the number of bytes used to represent it in a given encoding (that same emoji uses 8 and 10 bytes in UTF-8 and UTF-16, respectively).
 
 Practically, the encoded length of the string in bytes as observed on input or output by the user may vary depending on which of the valid JSON encodings are used (UTF-8, UTF-16, or UTF-32). Therefore, the value limit of 128k code points could take up to 512KB using the least space efficient allowable encoding, UTF-32, which uses 4 bytes per code point.