SSH access to investigate build or test failures

User story

The developer uploads a package and there's an unexpected build failure. This can be due to using another architecture (arm, s390x...), or hitting a peculiarity of the build/autopkgtest environment (unshare, overlayfs, tmpfs, network isolation, eatmydata, disk space, available memory... speaking for experience? ;)).

SSH/shell access, to investigate build and test failures, would be time-saving for the developer, and resources-saving for debusine (since the dev won't have to re-run a full lengthy workflow from scratch to test every single fix attempt) :)

SourceHut has been providing this for a few years:
https://drewdevault.com/2019/08/19/Introducing-shell-access-for-builds.html
https://yotam.net/posts/sourcehut-build/

[#1273143] 2024/07/11 00:17:50 Build failed.
[#1273143] 2024/07/11 00:17:50 The build environment will be kept alive for 10 minutes.
[#1273143] 2024/07/11 00:17:50 To log in with SSH and examine it, use the following command:
[#1273143] 2024/07/11 00:17:50 
[#1273143] 2024/07/11 00:17:50 	ssh -t builds@fra01.builds.sr.ht connect 1273143
[#1273143] 2024/07/11 00:17:50 
[#1273143] 2024/07/11 00:17:50 After logging in, the deadline is increased to your remaining build time.

GitLab has a "Web Terminal" feature:
https://docs.gitlab.com/ci/interactive_web_terminal/
though not available on shared runners (e.g. Salsa CI).

There are similar open tickets for Salsa CI:
salsa-ci-team/pipeline#363
salsa/support#148

We waste far too much time investigating CI failures, rather than actual regressions.
Many times in LTS/ELTS I saw tests disabled rather than being investigated due to time constraints, sometimes missing regressions.

I believe this would be a killer feature and contribute to attract people to Debusine.