Fix #220: antimeridian wrap in point-mode loadViewportSamples()

[rdhyee]

Fix #220 — antimeridian wrap in point-mode loadViewportSamples()

Closes #220 (the pre-existing wrap bug explicitly scoped out of #219).

Bug

loadViewportSamples() computed its own 30% padding from raw getViewportBounds() and emitted a single longitude BETWEEN padded.west AND padded.east. At a viewport that wraps the antimeridian (e.g. west=170, east=-170), west > east, so BETWEEN a-larger AND a-smaller matches zero rows (and bounds.east - bounds.west is negative, so the inline lngPad was meaningless too). The table was already correct there (routed through viewerBboxSQL since #219); only point mode + its "Samples in View" count (computed off the same WHERE) read 0 / undercounted near the dateline — so the two surfaces diverged.

Fix

Route loadViewportSamples() through the same viewerBboxSQL('latitude', 'longitude', VIEWPORT_PAD_FACTOR) helper the table uses. It emits the split (lng BETWEEN west AND 180 OR lng BETWEEN -180 AND east) for the wrap case and normalizes post-padding overflow back into [-180,180]. Point mode, the in-view count, and the table now share one wrap-aware bbox. The vestigial bounds arg to renderSamplePoints is left untouched (out of scope).

Verification

• Native (real lite data, dateline viewport west=170/east=-170): old longitude BETWEEN 170 AND -170 → 0 rows; wrap-split → 31,441.
• Both the data query and the cap-COUNT(*) query reuse the fixed whereClause.
• Codex review: LGTM — confirmed WHERE 1=1${bboxSQL} is valid (filter helpers return '' or AND …), non-wrapping behavior is identical, and the only remaining raw longitude ranges are the out-of-scope meta.lng ± delta point-selection queries.
• EXPLORER_STATE.md §6 updated (was "known bug NOT fixed" → "FIXED in Point-mode loadViewportSamples() doesn't wrap-split longitude predicate after antimeridian padding #220").

Scope

Single-file, low-risk: loadViewportSamples() + two doc updates. Independent of the #305 facet-count stack.