Describe the bug

georadiusGeneric in geo.c leaks the polygon points allocation when a valid BYPOLYGON argument is followed by an invalid COUNT argument. The COUNT parsing branch (lines 599-603) has bare return statements that skip geoPolygonPointsFree(), leaking 48 bytes per malformed command (3 vertices × 2 doubles × 8 bytes).

This is client-triggerable — any client can send malformed GEOSEARCH commands repeatedly to leak memory until OOM.

To reproduce

GEOADD points 151.2093 -33.8688 "Sydney"

# Non-numeric COUNT — leaks 48 bytes each time
GEOSEARCH points BYPOLYGON 3 151.2039 -33.8744 151.2132 -33.8829 151.2229 -33.8839 COUNT notanumber

# Negative COUNT — same leak
GEOSEARCH points BYPOLYGON 3 151.2039 -33.8744 151.2132 -33.8829 151.2229 -33.8839 COUNT -1

Confirmed with macOS leaks tool: 100 commands → 117 leaks, 9,136 bytes total.

Expected behavior

The polygon points allocation should be freed before returning on error. The COUNT parsing branch should use goto cleanup or call geoPolygonPointsFree(&shape) before returning, consistent with every other error path in the function (lines 676, 686, 693, 699, 705, 723, 745).

Additional information

The fix is straightforward — replace the two bare return statements in the COUNT branch (lines 599, 601-603) with a pattern that frees the polygon allocation first. Every other error path after the polygon parsing section already calls geoPolygonPointsFree(&shape).

Other argument branches (FROMMEMBER, FROMLONLAT, BYRADIUS, BYBOX) are not affected because they are guarded by !bypolygon and cannot be reached after polygon allocation.

This issue was generated by AI but verified, with love, by a human.