[shinaoka]

Accepts pylibsparseir 0.15 and releases 2.1.8 (range-only change, so both in one PR).

Range: >=0.8.3,!=0.13.*,<0.16.0 (was <0.15.0), in pyproject.toml and both
.conda/meta.yaml requirements; check_libsparseir_version_consistency.py passes.

Why the upper bound only. The C header at v0.15.0 is byte-identical to
v0.14.0 — 403 lines, cmp clean after stripping comments:

$ diff old.h new.h | grep '^<'   # empty
$ cmp -s old.h new.h && echo IDENTICAL
IDENTICAL

The two changes in 0.15.0 are inside existing entry points:
spir_sve_result_from_matrix_centrosymmetric runs its SVD in double-double again
when the low parts are supplied (SpM-lab/sparse-ir-rs#293), and the Fortran
binding checks FMA before its first numerical call (#353). No signature, no
status code, no new symbol — so nothing in the ctypes layer changes and older
backends keep working.

Tests (uv run --with 'pylibsparseir==X' pytest tests/ -q):

backend	result
0.15.0 (newest)	356 passed
0.14.0	356 passed
0.8.3 (oldest in range)	350 passed, 5 xfailed, 1 failed: test_boundary.py::test_c_library_failure_surfaces_as_exception

The 0.8.3 failure is pre-existing and unrelated: the same test fails on
mainline with this change stashed. This PR does not touch the lower bound.

pylibsparseir 0.15.0 is on PyPI and in the spm-lab conda channel, so CI
resolves it.