Fix hourly/day-night icon selection using a stale source timestamp instead of real time

[reveler-hub]

Related to #1095, #1088.

What

weather.current.time is a source's own reported observation timestamp (e.g. BMKG's presentwx datetime field), not the real current time. Sources can lag the real clock by a few minutes - confirmed live against BMKG's endpoint (~10-15 min lag). That's enough to cross an hour boundary near the top of the hour, which several UI call sites used as their "now" anchor:

• HourlyCard.kt - which hourly slot gets highlighted as current
• CurrentWeatherCard.kt, FroggyContainer.kt, NotificationWeatherMapper.kt - day/night icon selection
• BackgroundGradients.kt, WeatherAnimations.kt - day/night background art
• DailyScreen.kt - "now" anchor when viewing today's hourly breakdown

A reporter's screenshot on #1095 showed this exactly: device clock at 2:10 PM, but the hourly forecast highlighted 1 PM as current.

Most of the codebase already has the correct pattern for this - getCurrentTimeFor(zoneId) (real device time, converted to the location's zone), already used by the widget/notification hourly-index lookups and the JMA/AEMET/CWA/IMD/MetOffice mappers, sun/moon blocks, etc. This PR just brings the handful of remaining call sites in line with that. NotificationWeatherMapper.kt was actually inconsistent within itself - it already used getCurrentTimeFor for the hourly index but not for the icon a few lines above.

Left alone on purpose: weather.current.time usages in the per-metric detail screens (Humidity/Rain/Snow/Wind/etc. under feature/blocks/screens/) - those use it to label which timestamp the "current" data point on the chart represents, not to decide what "now" is, so they're a different use case.

Testing

Reproduced live on an AVD with mock location set to Jakarta, BMKG source: before the fix, with real device time at 2:27 PM the hourly forecast highlighted 13:00; after the fix, at 2:48 PM it correctly highlights 14:00 with fresh values. ./gradlew :app:compileDebugKotlin and :app:assembleDebug both clean.

AI disclosure

Used Claude (Anthropic) to investigate the reports, trace the root cause across call sites, and implement/verify this fix on-device.

[PranshulGG]

@reveler-hub No matter what, it will always show the previous hour because findMatchingHourly() will always return it. That is how it is intended to work. I think it's mostly a highlighting issue. That's why 1 PM is highlighted when the current time is 2 PM, so it's more of a minor UI fix rather than an issue with weather.current.time.

getCurrentTimeFor(zoneId) was intended to be used when sources don't provide that timestamp. But it also looks like using weather.current.time has the drawback of showing old data because the time is usually set when it is saved in the DB, meaning it won't really update the hours because the time is outdated

I'm trying to make the architecture more centered and be more intentional

This should be fixed with that change.

Also, I'm adding a new GitHub Action to only allow contributions to issues that are marked as "open to contributing." This should make it easier for contributors to know what to work on and prevent us from ending up working on the same issue!

Thanks!

[reveler-hub]

Hey, fair points — sounds like your architecture pass will cover this better than a standalone fix would. Closing this in favor of that.