docs: clarify how coordinates stored in tables are treated

[jan-glx]

(Stacked on #1273)

The SpatialData class docstring said that tables are stored as AnnData objects "with the spatial coordinates stored in the obsm slot". The library moved away from table coordinates early on (#123): tables have no coordinate system (design doc), and spatialdata never transforms, queries or validates coordinates stored in a table. The old line has likely contributed to recurring confusion, e.g. squidpy finding NaNs in obsm["spatial"] (#387), spatial queries ignoring centroids stored there (#573, #825), and queries crashing on tables that only carry obsm["spatial"] (#1248).

At the same time, obsm["spatial"] is the squidpy/scanpy convention (squidpy's default spatial_key, scanpy's sc.pl.spatial(basis="spatial")) and is populated widely in practice: by most spatialdata-io readers (xenium, visium, visium_hd, merscope, cosmx, dbit, mcmicro, steinbock), by the legacy-AnnData converter, and by spatialdata-plot's measure_obs (scverse/spatialdata-plot#705).
This PR therefore replaces the line with a description of the actual behaviour that names obsm["spatial"]
explicitly:

- tables are stored as :class:`anndata.AnnData` objects. Tables have no coordinate system: coordinates
  stored in a table (e.g. in ``obsm["spatial"]``, the squidpy/scanpy convention that several spatialdata-io
  readers populate) are currently not transformed or used by spatial queries, and can get out of sync with
  the SpatialElements the table annotates.