fix(metrics): return NaN when FSC/FRC curve never legitimately crosses threshold - #45

Please address the comments from this code review:

## Overall Comments
- In `_remove_small_objects`, passing `max_size=min_size - 1` will produce `max_size <= 0` when `min_obj_size`/`min_size` is 0 or 1; consider explicitly short‑circuiting those cases (e.g., returning the input unchanged) to avoid surprising behavior or warnings from skimage.
- The logic for setting NaN resolutions when the root is invalid is now duplicated between the `fit_start is None` path and the new `root` range check; consider refactoring this into a small helper to keep the NaN-resolution behavior centralized and harder to drift over time.

## Individual Comments

### Comment 1
<location path="cubic/metrics/spectral/analysis.py" line_range="396-401" />
<code_context>
             difference = y - thr
             crossings = np.where(difference <= 0)[0]
             if len(crossings) == 0:
-                return None  # No threshold crossing found
-            return x[crossings[0] - 1] if crossings[0] > 0 else x[0]
-
+                # Never crosses the threshold — resolution is beyond Nyquist
+                # (or the prediction is so close to GT that FSC stays above
+                # threshold everywhere). No measurable resolution: return NaN
+                # rather than reporting Nyquist as a floor.
+                return None
+            if crossings[0] == 0:
+                # Curve starts already below threshold at the lowest measured
</code_context>
<issue_to_address>
**nitpick:** Clarify mismatch between comments promising NaN and the function returning `None`.

The new branches in `first_guess` say "Return NaN" but still return `None`. Please either update the comments to describe returning `None` (e.g., "signal no resolution") or change the code to actually return `np.nan` so the function’s contract is explicit and future readers don’t assume it returns NaNs directly.
</issue_to_address>

### Comment 2
<location path="tests/metrics/spectral/test_frc.py" line_range="766-768" />
<code_context>
+    # Case 1: below-threshold-everywhere curve (zero-correlation prediction).
+    below = FourierCorrelationData()
+    below.correlation["frequency"] = freqs
+    below.correlation["correlation"] = 0.02 + 0.05 * np.random.default_rng(
+        0
+    ).standard_normal(50)
+    below.correlation["points-x-bin"] = np.full(50, 100.0)
+    coll = FourierCorrelationDataCollection()
</code_context>
<issue_to_address>
**suggestion (testing):** Avoid relying on a specific random draw for the below-threshold curve and use a deterministic construction instead.

Relying on a random normal draw (even with a fixed seed) makes it non-obvious that the curve is always below 0.143 and risks future changes to the seed/distribution breaking that guarantee. Instead, set `below.correlation['correlation'] = np.full_like(freqs, 0.05)` (or another constant < 0.143) so the "always below" condition is explicit and robust.

Suggested implementation:

```python
    # Case 1: below-threshold-everywhere curve (zero-correlation prediction).
    below = FourierCorrelationData()
    below.correlation["frequency"] = freqs
    # Use a deterministic, always-below-threshold correlation curve.
    below.correlation["correlation"] = np.full_like(freqs, 0.05)
    below.correlation["points-x-bin"] = np.full(50, 100.0)

```

1. If `np.random` / `default_rng` is only used in this block within the test file, you can safely remove any related imports (e.g., `import numpy.random` or similar) at the top of `tests/metrics/spectral/test_frc.py` to keep dependencies clean.
</issue_to_address>