Coverage job races on same-named coverdata when the OTP matrix has more than one entry

[Taure]

The Coverage job intermittently fails with a truncated coverdata file:

===> Importing file .../_build/test/cover/ct.coverdata
{badarg,[{erlang,binary_to_term,[<<131,104,2,104,6,119,4,98,117,109,112,...>>],...},
         {cover,get_term,1,[{file,"cover.erl"},{line,2991}]},
         {cover,do_import_to_table,4,...}]}
===> Uncaught error in rebar_core

Cause

download-artifact runs with pattern: coverdata-* and merge-multiple: true, so every matched artifact extracts into the same _build/test/cover. With a multi-entry OTP matrix the artifact names are distinct but the files inside them are not:

coverdata-eunit-otp29  ->  eunit.coverdata
coverdata-eunit-otp28  ->  eunit.coverdata   <- same path
coverdata-ct-otp29     ->  ct.coverdata
coverdata-ct-otp28     ->  ct.coverdata      <- same path

Two extractions race on one path; the loser leaves a partially-written file and cover:get_term/1 fails on it.

Consistent with the symptoms: it is intermittent (a re-run of the identical commit passes), and it only appears on repos with more than one OTP version. Taure/kura runs OTP 28 and 29 and flakes; widgrensit/asobi pins otp-matrix: '["29.0.2"]' and has never seen it.

It also means that when it does succeed, one matrix entry's coverage silently replaces the other's rather than merging - so the reported percentage is one OTP version's, not the union. That is arguably the worse half of the bug, because it is invisible.

Fix

Give each artifact its own directory and let covertool/cover import them all:

- uses: actions/download-artifact@...
  with:
    pattern: coverdata-*
    path: _build/test/cover      # no merge-multiple

then import every *.coverdata found beneath it. Alternatively have the producing jobs write matrix-qualified filenames (ct-otp28.coverdata) so a flat merge cannot collide.

Found while merging Taure/kura#167 and #168, which failed and then passed on re-run with no code change.