Allow HTTPFetcher to pass through 304 responses

[sonnyb9]

Summary

This updates js/http_fetcher.js so HTTP 304 Not Modified responses are emitted through the normal response event instead of being treated as errors.

That aligns the core fetcher with the built-in yr weather provider in v2.35.0, which already includes explicit logic to handle 304 and reuse cached data.

Closes #4119.

Root cause

HTTPFetcher currently treats all non-OK responses as errors. Since 304 is not an OK response, it never reaches providers listening on the response event.

At the same time, defaultmodules/weather/providers/yr.js expects to receive 304 and handle it by reusing cached data.

What changed

• special-case HTTP 304 in HTTPFetcher
• emit 304 through the normal response event
• preserve the existing error path for other non-OK statuses

Validation

• confirmed defaultmodules/weather/providers/yr.js already expects response.status === 304
• compared the unpatched v2.35.0 HTTPFetcher behavior to the provider logic
• ran node --check js/http_fetcher.js

[rejas]

Please base your PR against the develop branch

[KristjanESPERANTO]

This would skip the error count reset for 304s - but a 304 means the server is healthy, so serverErrorCount/networkErrorCount should still be cleared.

This would fix that:

			const isSuccessfulResponse = response.ok || response.status === 304;

			if (!isSuccessfulResponse) {

The reset would happen in the else branch.

Additionally, we could even reverse the if condition to handle the happy path first, which would make the code even easier to understand. That wouldn't strictly fall within the scope of this PR, but it would be a small refactoring that I would consider as a minor acceptable tweak.