fix(pipeline): reject estimator keywords instead of discarding them

[sgjholt]

estimate_spectrum filtered the caller's **kwargs to what the selected
estimator accepts and dropped the rest, silently. A typo did nothing. An
argument meant for a different stage did nothing.

Filtering the configuration that way is correct and stays: [transform]
holds every estimator's settings at once, so a CWT parameter is not an error
when the FFT is running. The caller's own keywords are a different thing —
they were written deliberately, and one the estimator does not recognise is a
mistake rather than a setting for someone else.

This is not hypothetical. spectrum_set_from_streams(rotate_noise=False)
reads exactly as though it disables the noise lift; rotate_noise belongs to
compare, so it was dropped here and the run silently kept the configured
value. I took three measurements against what I believed was a modified
pipeline and was not, and concluded from them that a documented explanation
of a known inconsistency was wrong. It was not — the recorded settings on the
pair are what gave it away.

The error names the offending keywords, lists what the estimator does take,
and — when the keyword is one of compare's — says so and shows the spelling
that works:

fft does not accept rotate_noise. It takes drop_dc, n_fft, name, taper,
taper_alpha, taper_correction. rotate_noise configures the signal-to-noise
comparison, not the transform — pass it as compare={'rotate_noise': ...}.

Four tests: an unknown keyword raises, a compare keyword raises with the
redirect, the message names the valid parameters, and a keyword the estimator
does take still changes the answer — the passthrough is the point of the
parameter and rejecting unknown keys must not break it.