fix(firms): keep the IPv4 retry from crashing the server; guard the call sites

- fetchIpv4 builds its Response inside the https response callback, outside
  the promise. A 204, 205 or 304, a status above 599 or an invalid reason
  phrase made the Response constructor throw there, an uncaught exception
  that stops the dev server. Null-body statuses now get a null body and
  anything else that cannot become a Response rejects, as the Radio Browser
  transport does.
- A non-OK FIRMS or mapkey-status response cancels its body so the IPv4
  socket closes at once instead of at the deadline.
- Tests: the crash cases (fail on the old code), a source check that every
  upstream request goes through fetchFirms and that fetchSource's body read
  shares its deadline (fails if either call reverts to fetch), a real-fetch
  contract test for the address-selection error shape, and an explicit skip
  in the IPv4-only socket test where the host cannot tell the families apart.
- Changelog entry moves to changelog.d/1078-firms-ipv4-fallback.md per
  CONTRIBUTING; CURRENT-STATE says which timeouts are retried and that the
  retry does not follow redirects.

docs/CURRENT-STATE.md

@@ -2118,10 +2118,14 @@ FIRMS requests retry once over IPv4 when every resolved address fails to
 connect. Node's network-family auto-selection gives each address a short
 attempt timeout, so on hosts where IPv6 is unreachable a slow IPv4 handshake
 was abandoned and the request reported only `fetch failed` (#68). The retry
-makes a single IPv4 connection within the same deadline; HTTP errors,
-timeouts and DNS failures are not retried. FIRMS warnings include the
-per-address connection errors and never the request URL, which embeds the
-MAP_KEY.
+makes a single IPv4 connection within the same deadline and the same body
+cap, and does not follow redirects. HTTP errors, an expired request deadline
+and DNS failures are not retried; a per-address connect timeout, which Node 26
+reports as `ConnectTimeoutError`, is. A retry answered with a null-body status
+(204, 205, 304) or a status above 599 fails that source instead of crashing
+the server, and a non-OK response releases its connection at once. FIRMS
+warnings include the per-address connection errors and never the request URL,
+which embeds the MAP_KEY.
 
 ## Installations and map-source guidance