Downsampled series for plotting

Glucose downsampled to a target number of points for drawing a chart, with a min/max band per point so spikes are not lost, plus bolus events as overlay markers.

Use this whenever the patient wants a GRAPH or CHART of glucose over a window, or when illustrating "what a good/bad day looked like" — a picture of the trace is far more useful here than a table of numbers. It returns a few hundred points instead of every 5-minute reading, so it is far cheaper than get_glucose and a chart cannot show more points than its pixel width anyway. Reserve get_glucose for close-up numeric inspection of a short window, not for wide charts.

IMPORTANT — this tool returns DATA, not a picture: after calling it, actually render the points as a visual line/area chart with time on the x-axis and glucose on the y-axis, shading the target range and marking boluses, rather than only describing the numbers in prose. Producing that chart is the point of calling this tool at all.

HOW TO RENDER IT — DO NOT use a quick/built-in auto-chart shortcut for this: any lightweight "visualize this data" feature that infers its own axis from a plain array almost always falls back to plotting by point POSITION (1, 2, 3, ...) because it never looks at the t field or the xAxis data below — this has been confirmed to happen and produces a meaningless, unlabelled time axis. Instead, BUILD A CUSTOM CHART YOURSELF (e.g. an HTML/SVG or JS-charting-library artifact you write) where you explicitly control the x-axis scale and can use the xAxis data below directly. If your environment offers both a quick chart shortcut and the ability to write custom HTML/code, always choose the custom option for this tool's output.

X-AXIS — READ THIS CAREFULLY, this is commonly gotten wrong: the x-axis MUST be a genuine TIME SCALE, NEVER a plain category/index axis showing point position (1, 2, 3, ... maxPoints, or "286"). Points are NOT evenly spaced in time (a sensor gap or the short-fidelity path below means the interval between consecutive points can vary), so an index axis silently distorts time and every tick is meaningless to the reader.

To make this hard to get wrong, the response includes a ready-made xAxis object — USE IT DIRECTLY instead of inventing your own tick scheme:

• xAxis.ticks: an array of {t, label} already spaced sensibly for the window's span (every 3-4 hours for anything up to ~10 days, daily beyond that). Plot these as the x-axis tick marks, using label as the tick text VERBATIM — do not recompute your own tick positions or labels.

• xAxis.days: one {startT, endT, label} entry per calendar day the window touches (e.g. "Wed 17 Jun"), present whenever the window spans more than a single day. For a multi-day chart, this is what makes it read correctly: divide the plot into these segments with a vertical divider at each boundary, and print each segment's label centred underneath — e.g. three equal sections labelled "Wed 17 Jun", "Thu 18 Jun", "Fri 19 Jun" for a 3-day window, each showing that day's own hour ticks above it. This is exactly the "N equally spaced, dated sections" layout a multi-day glucose chart needs. days is empty for a single-day window (nothing to divide) and for very long windows (too many days to label individually — ticks switches to one date label per tick there instead).

• A gap in the data (missing points) must still show as a visual gap or interrupted line against this time scale — never compressed away.

Glucose values are in the configured unit; times are plain wall clock time (device-local), not UTC.

Returns: unit, a points array (t, avg, min, max, n per point), an events array of bolus markers for overlay, and xAxis (spanHours, ticks, days) as described above.