Handle OSM API connection timeouts and network errors

[Copilot]

Network-level errors (ERR_CONNECTION_CLOSED, ERR_TIMED_OUT) thrown by fetch as TypeError were silently swallowed in OsmService.js catch blocks, which only handled AbortError and FetchError. This meant the app got no feedback and no apistatuschange event when the OSM API was completely unreachable.

Changes

• All fetch catch blocks (loadFromAPI, openChangeset, uploadChangeset, closeChangeset, postNote, postNoteUpdate): removed the FetchError-specific guard so all non-abort errors are forwarded to the error callback:

  // Before — TypeError falls through silently
  .catch(err => {
    if (err.name === 'AbortError') return;
    if (err.name === 'FetchError') { errback(err); return; }
  });
  
  // After
  .catch(err => {
    if (err.name === 'AbortError') return;
    errback(err);  // FetchError or network error (e.g. TypeError from connection timeout)
  });

• status(): added AbortSignal.timeout(10000) to the capabilities fetch so a hanging connection fails fast instead of waiting for the OS TCP timeout (2+ min).

  fetch(url, { signal: AbortSignal.timeout(10000) })

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Handle OSM API Timeouts</issue_title>
<issue_description>Followup on #1304
We already handle a bunch of different error conditions with the OSM API.
But when things get really bad, we don't even get a response from the capabilities or any of the other calls, just a connection timeout:

We should handle this situation too.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Handle OSM API Timeouts #1487

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.