[antonsoo]

Integer lags and frequencies currently fail when the floating-point kernel result is added to an integer output array:

import numpy as np
from celerite2 import terms

kernel = terms.RealTerm(a=1.2, c=0.3)
assert np.allclose(kernel.get_value(np.arange(3)),
                   1.2 * np.exp(-0.3 * np.arange(3)))
assert np.allclose(kernel.get_psd(np.array([0, 1])),
                   np.sqrt(2 / np.pi) * 1.2 * 0.3 / (0.3**2 + np.array([0., 1.])**2))
print('complete')
# Before: integer-to-float casting error; after: complete

Promote evaluation inputs to at least float64 before taking absolute values or squaring. This also avoids overflow at the minimum signed integer and during integer frequency squaring. Preserve extended floating precision, and apply the same promotion to the exposure-convolution wrappers so their intermediate calculations use the promoted dtype.

Tests cover real, complex, SHO and convolved kernels, integer and float32 arrays, integer extrema and extended precision. The native/core suite passes with 10 optional-backend skips, and all configured pre-commit hooks pass. Separate sampled-signal workflows match analytic covariance/spectral references and SciPy dense solves; the existing float64 native inference results remain identical.