web,server: every hex refresh runs /api/heatmap's point query twice, once per cell size #742

Since #734 the website draws two cell sizes at a time, and drawHex (web/map.js:475-489) asks /api/heatmap once per size. Each ask runs its own QueryPoints up to heatmapCap (50 000 rows, server/internal/httpapi/api.go:167) and bins the same rows again at its own resolution.

What happens

• Every refresh of the hex layer costs two full point queries: every pan, every filter change, and every 10 s tick of a live time range.
• For a guest above zoom 12 both asks are answered at res 12 (guestHeatmapMaxZ, server/internal/httpapi/degrade.go:15), so the second query returns the same cells as the first. drawHex already recognises that case after the fact (capped), but only after both queries have run.

Expected
One point query per refresh, binned into both sizes.

Proposal
Let /api/heatmap take two resolutions (for example z=13,14) and return one FeatureCollection per size from a single QueryPoints, with the same degrade rules per caller. drawHex then sends one request. When the caller's ceiling folds both sizes into one, the server answers that size once.

Scope options for whoever picks this up:

• (a) server z=a,b plus the one-request drawHex, as above;
• (b) client only: ask one size once an earlier answer showed the cap, and keep two requests otherwise;
• (c) both.

Raised in the review of #734 (point 4), where it was left for a follow-up.