fix: replace hardcoded St. Petersburg weather with IP geolocation

[ethanplusai]

Summary

The background context worker in `server.py` had Open-Meteo coordinates and a location label hardcoded to St. Petersburg, FL (lat 27.77, lon -82.64), so every JARVIS install — anywhere in the world — reported St. Pete weather. Embarrassing for anyone running this outside Tampa Bay. 🌴

What changed

• Resolves location dynamically via ipwho.is (no API key required), cached for 15 minutes
• New env overrides in `.env.example` for pinned locations:
  • `WEATHER_LATITUDE` / `WEATHER_LONGITUDE` (required pair)
  • `WEATHER_LOCATION_LABEL` (display string, optional)
  • `WEATHER_UNIT` (`fahrenheit` | `celsius`, default `fahrenheit`)
• Defaults to Fahrenheit to preserve existing behavior for the original Floridian audience
• Silent fallback to "Weather data unavailable." if both env override AND IP lookup fail — no behavior regression
• Removes the dead `async def fetch_weather()` wttr.in helper that wasn't called from anywhere; the only live weather path was the background worker writing to `_ctx_cache`

Test plan

• `python3 -m pytest tests/ -q` — all 26 existing tests pass
• Live IP-geolocation smoke test: correctly resolves to the caller's actual city via ipwho.is
• Live env-override smoke test: `WEATHER_LATITUDE=51.5074 WEATHER_LONGITUDE=-0.1278 WEATHER_LOCATION_LABEL=London WEATHER_UNIT=celsius` → `"Current weather in London: 8.0°C"`
• No merge conflicts with `main`

Approach adapted from @devon7y's larger PR #4, extracted as a focused, standalone change.

🤖 Generated with Claude Code