Clarify uniqueness of index for points and shapes

Points and shapes are not required to have an unique .index. On the other hand the instance_key obs column of a table requires unique values, and usually shapes (more rarely also points) are annotated by a table. So effectively the uniqueness constraint of the instance_key obs column is transferred to the .index of the shapes or points dataframe.

This can create confusion (one could understand that the index of points and shapes is always unique). For instance this bug https://github.com/scverse/spatialdata/issues/1105 is related to non-uniqueness of Xenium transcripts.

When the new design for inter-element relationships lands (see https://github.com/BiocCodingCollaborations/VeniceHackathon2026/tree/main/interoperability/relationships), this case should be clarified. Also validators will be added to detect/ensure uniqueness when expected.

CC @timtreis

Start by reading issue #1105 and the linked inter-element relationships design to understand the non-unique Xenium transcript case. Define how index uniqueness should be communicated and how future validators should detect or enforce it; the work is done when the expected behavior is explicitly settled.