coverage: Also use clusterd binary when running SLT

[def-]

As noticed in #18966

Motivation

• This PR fixes a previously unreported bug.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• This PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way) and therefore is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[ggevay]

I have to admit that I don't understand the changes in this PR, but I rebased #18966 on top of this PR, and started a coverage run to see if it fixes the problem: https://buildkite.com/materialize/coverage/builds/92

[def-]

I did the same and the result looks good to me now: https://buildkite.com/materialize/coverage/builds/91

[def-]

I have to admit that I don't understand the changes in this PR, but I rebased #18966 on top of this PR, and started a coverage run to see if it fixes the problem: https://buildkite.com/materialize/coverage/builds/92

As an explanation for what this does: In the SLT test only the sqllogictest container is running, so we were only copying out the sqllogictest binary and aggregating the coverage information for it. Now we also copy out the clusterd binary from sqllogictest container and aggregate the coverage information for it too.