Fix the error band, and let a caller read back whether it is drawn

[cboulay]

Two small things on top of v0.9.0, found by driving the trace grid against live
hardware.

The band raised on every frame

Turning on show_error made _curve_positions pass the band -- the lower and
upper edges stacked, 2 x n_ch rows -- to _map_y, which maps amplitudes into
per-channel cells and so expects n_ch:

mean, (n_ch, m)     -> (4, 10)
band, (2*n_ch, m)   -> ValueError: operands could not be broadcast together
                       with shapes (8,10) (4,1)

Each per-channel block is now mapped on its own.

It surfaced as a warning that points nowhere near it:

UserWarning: Could not resolve argspec of Figure animation function ...
calling it without arguments.

fastplotlib wraps both the argspec check and the call to an animation function
in one try, catching ValueError and TypeError. An exception raised inside
the callback is therefore reported as a failure to introspect it, and the
callback is called a second time. getfullargspec on the lambda works fine --
the message is simply misleading about its own cause, which is worth knowing for
anyone else who sees it.

The tests could not have caught it

make_widget stubbed _map_y with the identity -- precisely the collaborator
whose contract the band violated. One of those tests asserts the band has
2 x n_ch rows: the exact shape that raises, checked against a stub that
cannot. The tests now build the real _map_y, and the two that read raw
amplitudes off drawn y values compare through the mapping instead. Three fail
with the fix reverted.

show_error can be read back

set_show_error had no counterpart, so a caller could ask for the band but not
find out whether it got one. It reports the resolved value rather than the
request: asking for a band with statistics switched off resolves to off, and a
caller persisting the request would restore a setting that never took effect.

127 tests.

🤖 Generated with Claude Code