feat: weather consensus

[Mygod]

Fixes #325. Needs testing.

[jfberry]

What is the logic you have applied here?

[Mygod]

• Added a per-S2-cell/hour consensus layer for weather updates via a new weatherConsensusCache (TTL 2h) and WeatherConsensusState helper that tracks votes per account, counts per condition, and the last proto for each condition (decoder/weather_consensus.go, decoder/main.go).
• UpdateClientWeatherBatch now takes the reporting account and feeds each observation into that consensus; the weather record is saved/published only when the state decides to publish—first observation in the hour publishes, later flips only if a new condition’s count is strictly higher than the runner-up to avoid flapping from conflicting scans (decoder/main.go).
• Consensus state resets on hour rollover, ignores stale-hour data, dedupes/rebalances when the same account changes its vote, and uses the last proto of the winning condition when writing to DB and emitting WeatherUpdate (decoder/weather_consensus.go).
• decodeGMO now passes protoData.Account into the weather updater so votes are keyed by account rather than raw observation count (main.go).

[jfberry]

Claude suggests this comment to describe the algorithm for future readers, if it's accurate this might have helped me navigate the code. This seems like a sensible approach - I'll look at the code in more detail later

// Weather Consensus Algorithm
  //
  // Pokemon Go performs A/B testing on weather conditions, meaning different accounts
  // may observe different weather for the same S2 cell at the same time. This causes
  // problems when multiple accounts report conflicting weather, leading to rapid
  // flapping of stored weather values and incorrect IV calculations for Pokemon.
  //
  // This consensus mechanism aggregates weather observations from multiple accounts
  // and only publishes updates when there is clear agreement:
  //
  // 1. VOTING: Each account gets one vote per cell. When an account reports weather,
  //    their vote is recorded. If they report again with a different condition,
  //    their previous vote is transferred to the new condition.
  //
  // 2. HOURLY RESET: Weather in PoGo changes on the hour, so consensus state resets
  //    when a new hour begins. Stale observations (from a previous hour) are ignored.
  //
  // 3. FIRST OBSERVATION: The first observation of each hour is always published
  //    immediately to ensure we have some weather data, even if only one account
  //    has reported.
  //
  // 4. SUBSEQUENT UPDATES: After the first publish, weather only changes if the
  //    leading condition's vote count STRICTLY exceeds the runner-up. This means:
  //    - Ties do not trigger updates (prevents flapping)
  //    - A clear majority is required to override the current weather
  //    - Single outlier accounts cannot flip the weather back and forth
  //
  // Example: If 3 accounts report "Cloudy" and 2 report "Sunny", we publish "Cloudy".
  // If a 3rd account reports "Sunny" making it 3-3, we keep "Cloudy" (no strict majority).
  // Only when "Sunny" reaches 4 votes would we switch.

[Fabio1988]

@jfberry this PR fixes as well the increased weather updates to DB. Testing this now 😀