feat(fitness/stats): 4 cm minimum y-axis range on body-part history charts

Body-measurement variation of <4 cm used to stretch the full chart
height, making normal weekly noise look dramatic. Now the y-axis
enforces a 4 cm floor centered on the data's midpoint; wider swings
render at their actual range as before.

- FitnessChart: new optional `yMin` / `yMax` props mapped to Chart.js
  `suggestedMin` / `suggestedMax` — soft bounds, so data that exceeds
  them still widens the axis.
- `/fitness/stats/history/[part]`: computes min/max across available
  values (both sides if paired), enforces the 4 cm floor, passes to
  FitnessChart. Tick distance stays on Chart.js auto — small ranges
  get 0.5 cm ticks, wider ones scale up naturally.

TODO.md

@@ -7,7 +7,7 @@
 [x] add a button on /fitness/measure/body-parts for each measurement directly below to say "Same value", instead of having to hit +, then - to lock in same number
 [x] BF graph (with trend line like weight graph) on /fitness/stats page. Emphasize relative changes, not absolute numbers in design (as we cannot trust those) (e.g., use start day of overview as 0% and then show +/- x % on the graph)
 [x] Workshop better names than "Measure" for the /fitness/measure route. It's about body data points (i.e., non-food related). What's a better, short name than "Measure" to capture the logging of weight, body composition, body part measurements, and period tracking?
-[ ] on /fitness/stats/histoy/<part> for body measurement graphs, make the range reasonable. e.g., if we have 1 cm change, do not fill the entire y-height with 1 cm. Use reasonable padding for low ranges (i think we do something like htis already on the weight graph?)
+[x] on /fitness/stats/histoy/<part> for body measurement graphs, make the range reasonable. e.g., if we have 1 cm change, do not fill the entire y-height with 1 cm. Use reasonable padding for low ranges (i think we do something like htis already on the weight graph?)
 
 ## Refactor Recipe Search Component