Attempt to fix the so frequent CI failures due to download issues.

[joa-quim]

It's a trial. Issue is convoluted. Claude says

Why CI, and intermittently

gmtremote_refresh locks inconsistently:

- first-time branch, line 1017: gmtremote_get_url(..., indexpath, ..., do_lock=true) → lock held on gmt_data_server.txt
- refresh branch, line 1056: gmtremote_lock_on(new_indexpath) → lock held on gmt_data_server.txt.new, and get_url at 1067 is called with do_lock=false

Different lock names, so those two paths do not exclude each other. The refresh branch then renames indexpath → .old and .new → indexpath (lines 1076, 1082) while another process may be downloading, reading, or fopen-ing indexpath. gmt_refresh_server's own gmtremote_data_load call (line 1162) takes no lock at all.

Lose that race → data_load returns NULL → err1 → downloads off for that process. Next process usually recovers (both failure paths delete the bad index file), which is exactly the "fails many times, not always" pattern of a parallel ctest -j.

Assisted-by: Claude Opus 5.0

[Esteban82]

This is for the remote data sets, right?

[joa-quim]

Yes, because those CI failures are actually caused by the remote datasets download machinery and the parallel runs that propagate the problem.

[joa-quim]

@seisman can you please have a look at this. I don't believe it solved with this but it shouldn't harm either and at least posts more info when it fails.

[seisman]

I can still see the download issues in the Windows CI jobs.

[joa-quim]

Yes, this thing is damn random. Now it fails again on Linux.