Two-sided scale-use / offset bands on the panel scorecard

[kgdunn]

What and why

A front-end colouring a panel-consistency chart currently has to re-derive its
own thresholds from the raw scale_spread / scale_shift numbers to decide who
compresses, stretches, or rates high/low. Doing that on the magnitude alone
tends to paint the whole panel as a problem, and it easily reports one tail (say
expanders) while dropping the other (compressors).

This adds a stable, symmetric classification the panel check computes once, so
the front-end can bind to it instead.

What changed

• panel_scorecard now adds two columns per panelist:
  • scale_use_band - low (compresses the range) / normal / high
    (expands the range),
  • offset_band - low (rates consistently low) / normal / high (rates
    consistently high).
    Both use two-sided Tukey 1.5*IQR fences, so the two tails are surfaced
    symmetrically. The fence is intentionally looser than the ESD test used for
    dropping, because scale use and offset are corrected by alignment rather than
    dropped; the aim is to surface the genuine tails, not withhold all but the most
    extreme.
• Exposed through the agent tools: sensory_panel_check carries the two bands on
  each scorecard row, and sensory_analyze_descriptive gains a scale_bands
  block (panelist_id, scale_use_band, offset_band). Both tool descriptions
  document the new fields and how to use them (colour / label only the non-normal
  panelists).

Tests / verification

New unit tests assert the band columns exist and classify a planted expander as
high, a compressor as low, a typical panelist as normal, and a high rater
as high on offset; the analyze-tool test checks the scale_bands block is
exposed. ruff, mypy, and the sensory + recipe suites pass. Version bumped to
1.52.0 with CITATION and CHANGELOG in sync.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!