fix(backend): validate static-map coordinates before quantization

[Aj2280]

Summary

In backend/utils/static_map.py::parse_pins, latitude and longitude were previously rounded to _PIN_PRECISION (4 decimal places) before enforcing the [-90, 90] and [-180, 180] coordinate bounds. Because of this premature rounding, out-of-range coordinates that slightly exceed legal boundaries (such as 90.00004, 0 or 0, 180.00004) rounded onto the legal boundary (90.0 and 180.0) and were erroneously accepted.

This PR validates the raw parsed float coordinates against the legal bounds before applying the 4-decimal quantization used for de-duplication and cache keys.

Fixes #13249

Changes

• backend/utils/static_map.py:
  • Parse raw_lat and raw_lng as floats first.
  • Enforce -90 <= raw_lat <= 90 and -180 <= raw_lng <= 180 before rounding.
  • Apply round(..., _PIN_PRECISION) only to valid coordinates.
• backend/tests/routers/test_static_map.py:
  • Added boundary excursions (90.00004,0, -90.00004,0, 0,180.00004, 0,-180.00004) to test_malformed_pins_are_rejected_with_400.
  • Added test_parse_pins_rejects_out_of_bounds_coordinates_before_quantization testing both out-of-bounds rejection and exact boundary validity.

Product Invariants Affected

none

Failure-Class

Failure-Class: none

Verification

• Ran unit tests: pytest tests/routers/test_static_map.py (22/22 passed in 0.59s).
• Ran formatter: scripts/backend-python-format --write backend/utils/static_map.py backend/tests/routers/test_static_map.py.
• Ran manifest preflight: all checks passed.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[Git-on-my-level]

Verified the fix in backend/utils/static_map.py at the head commit: parse_pins now floats the raw pair, enforces the [-90,90]/[-180,180] bounds on the raw values, and only then applies round(..., _PIN_PRECISION). This closes the real acceptance gap where inputs like 90.00004,0 or 0,180.00004 rounded onto the legal boundary before the bounds check.

Everything downstream of the check is unchanged — quantization, de-dup, sorting, and the 50-pin cap behave exactly as before, so the only behavior delta is that genuinely out-of-bounds pins now (correctly) return 400. backend/routers/static_map.py remains the sole caller, so the blast radius is the one endpoint.

Test coverage is well targeted: the boundary excursions added to test_malformed_pins_are_rejected_with_400 and the new test_parse_pins_rejects_out_of_bounds_coordinates_before_quantization pin down both the rejection side and the exact-boundary acceptance side (90.0,180.0 / -90.0,-180.0 stay legal), which is exactly the pair of behaviors this fix must preserve. Backend Hermetic Merge Gate, Hermetic Backend E2E, Hygiene, and Formatting are green.

Clean, tight bug fix — nice work, and thanks for linking it to the bounty issue (#13249).

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[kodjima33]

Scoped backend bug fix (validate coords before quantization), tests added, CI green, not yet fixed on main.

[Aj2280]

Hi @kodjima33,

Thank you so much for merging my PRs (#13262, #13099, #13089, #13084, #13083, #13081, #13080, #13079)!

I wanted to politely clarify: are the bounties proposed on these issues real/active, and do these merged fixes qualify for any bounty payout? Support mentioned that because the issues didn't carry the official "Paid Bounty" label, only maintainers can confirm if retroactive bounties apply.

Also, I wanted to check if these qualify for the 5+ merged PRs contributor milestone reward (Free DevKit device).

Could you please clarify when you have a moment so I understand how bounties work here moving forward?

Really appreciate your time, guidance, and help!