Add tiling QC metric for tile-boundary segmentation artifacts

[timtreis]

Summary

• Adds sq.experimental.tl.calculate_tiling_qc — per-cell scoring that detects cells artificially cut by tile boundaries during segmentation, using collinearity-based straight-edge detection on contours
• Adds sq.experimental.pl.tiling_qc — diagnostic plot via spatialdata-plot where the tile grid emerges from high-scoring cells without requiring tile-border metadata
• Includes cell-aware tiling infrastructure (_tiling.py) for scalable labels-only tile extraction — will be shared with [EXPERIMENTAL]: Integrate cp-measure #982 when merged
• Scores stored in .obs of a QC AnnData table ({labels_key}_qc) with proper spatialdata_attrs linking and algorithm params in .uns["tiling_qc"]

Metrics

Metric	Description
max_straight_edge_ratio	Longest collinear boundary segment / equivalent diameter
cardinal_alignment_score	Axis-alignment of that segment (1 = cardinal, 0 = diagonal)

[codecov]

Codecov Report

❌ Patch coverage is 56.44028% with 186 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.56%. Comparing base (9aa7c09) to head (a8bea24).

Files with missing lines	Patch %	Lines
src/squidpy/experimental/tl/_tiling_qc.py	63.88%	73 Missing and 18 partials ⚠️
src/squidpy/experimental/im/_tiling.py	42.76%	82 Missing and 5 partials ⚠️
src/squidpy/experimental/pl/_tiling_qc.py	62.50%	3 Missing and 3 partials ⚠️
src/squidpy/_utils.py	71.42%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1157      +/-   ##
==========================================
- Coverage   73.56%   72.56%   -1.00%     
==========================================
  Files          44       47       +3     
  Lines        6929     7355     +426     
  Branches     1174     1245      +71     
==========================================
+ Hits         5097     5337     +240     
- Misses       1347     1507     +160     
- Partials      485      511      +26     

Files with missing lines	Coverage Δ
src/squidpy/_utils.py	57.51% <71.42%> (+0.29%)	⬆️
src/squidpy/experimental/pl/_tiling_qc.py	62.50% <62.50%> (ø)
src/squidpy/experimental/im/_tiling.py	42.76% <42.76%> (ø)
src/squidpy/experimental/tl/_tiling_qc.py	63.88% <63.88%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LLehner]

Just a general question: how is it currently decided whether a function should go into experimental?

[timtreis]

Just a general question: how is it currently decided whether a function should go into experimental?

currently pretty much "anything that actually uses sdata"

[selmanozleyen]

isn't this change unrelated to this PR? Do we really need it? Like have you seen os.cpu_count cause errors so far?

[selmanozleyen]

update: I now remember _get_n_cores. Why don't we modify that one instead?

[selmanozleyen]

Suggested change

	score_col: str = "nhood_outlier_fraction",
	score_col: Literal["nhood_outlier_fraction", "smoothed_cut_score", "cut_score", "max_straight_edge_ratio", "cardinal_alignment_score"] = "nhood_outlier_fraction",

[selmanozleyen]

I don't think getting client as an arg is the right approach here. In dask we usually would expect setting the client with a context manager I think. Something like this to get the client object if it exists:

# removing client from the function signature and not importing dask distributed at top level.
client = None
try:
    import dask.distributed as dd
    client = dd.get_client() # value error if there is no client active
except (ImportError, ValueError):
    client = None

but I am not sure of this suggestion. so @flying-sheep what do you think?

[selmanozleyen]

Not a strong suggestion but an opinion. I think key_added would be nicer. Or table_key_added. Because now I am not sure if this adds to the adata or adds the adata in this name

[selmanozleyen]

This is a bit weird to me.
We should either:

• Match only the expected format, e.g. ^scale(\d+)$, and fail clearly for unexpected keys.
• or choose the coarsest level by actual spatial shape, like the nearby _choose_label_scale_for_image() logic does, since “coarsest” is a property of the array dimensions, not the key string.

[selmanozleyen]

Besides the things I mentioned it looks good to me. Really depends on the feedback this will get, otherwise I feel like it would be early optimization to dig deeper.