Grid forecasts are live

Convek now has a grid endpoint. `/v1/grid` serves one field, one forecast hour, as a bounded slice. If you want to build a map, an embedded club page, or your own weather layer in an app, this is the route you were waiting for.

Until now, the API was point-first. `/v1/site` is great when you want one coordinate. `/v1/forecast` is great when you want the whole day at one point. Neither is the right shape for a map. Pulling hundreds or thousands of point requests just to colour a weather layer is wasteful, slow, and expensive. `/v1/grid` fixes that.

The first version is deliberately simple. You choose a field, a date, and an hour, then pass west, east, south, and north for the slice you need. The API returns a regular grid with metadata, dimensions, and the values as JSON arrays. That is enough to power a browser map, a dashboard card, an image renderer, or a club weather panel without committing to tiles yet.

The obvious fields are there from day one. `wstar_ms` for thermal strength. `cloudbase_agl_ft` and `cloudbase_msl_m` for ceiling layers. `day_rating` for coarse planning maps. Surface and 925 hPa wind layers. Rain. And the new horizontal flow diagnostics, `horizontal_convergence_s1` and `horizontal_divergence_s1`, which are much closer to proper line-finding inputs than the older convergence proxy alone.

This also changes what the developer plans can support. The Dev tier is no longer just point queries and corridor samples. It is now enough to build a real map-backed product on top of Convek. That matters for app developers, instrument makers, club sites, and anyone who wants to turn soaring weather into something more useful than a screenshot.

Why JSON arrays rather than map tiles first? Because this is the shortest honest path to something useful. A lot of early integrations do not need a slippy-map tile stack. They need a bounded slice they can render themselves, style themselves, and sample themselves. Tiles can come later when the map product needs them at scale.

There is another practical advantage. `/v1/grid` uses the same underlying Convek artifacts already serving the point endpoints. No separate map export pipeline. No second data product to keep in sync. The same run that serves `/v1/site` and `/v1/forecast` now also serves grid slices, which keeps the product coherent and the ops burden sane.

If you are building your own map layer, start on the developer page and then jump to the API docs. The endpoint is live now. The next step is putting it to work in the site map preview, club tools, and external apps.