The sbuild task reports "success" for packages that cannot be built on the requested architecture (Architecture: i386 vs. building on arm64)

Describe the bug

Observed in work request 43135 (sbuild task).

I scheduled a build of i810switch on arm64. The problem being that i810switch cannot be build on arm64 given its Architecture: amd64 hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 (arm64 vs. amd64).

The result was a "success" according to the debusine API and diving into the logs, we see:

[...]
E: dsc: arm64 not in arch list or does not match any arch wildcards: i386 kfreebsd-i386 amd64 hurd-i386 kfreebsd-amd64 -- skipping

aborted: False
returncode: 0
[...]

This is a mismatch in expectations, since this test rebuild have not validated that I can build i810switch in my changed environment. In a bulk test setting, I would likely have overlooked this as a problem since I would have trusted "success" to mean "Successfully rebuilt in the modified environment", not "Successfully did nothing, and you should schedule the build correctly next time".

Side note: Colin suggested that this problem would not affect sbuild workflows, only sbuild tasks.

How to reproduce the bug

Schedule a sbuild task with a package that has an architecture restriction (such as i810switch) to have it be build for an architecture that is not in the architecture requested (DEB_HOST_ARCH).

Runtime environment

It happened on debusine.d.n. The rebuild was in sid with a rebuild dpkg. The modified dpkg should not be affecting the outcome, since it is the debusine + sbuild side that causes this (already before the build can start).

Operating system

It happened on debusine.d.n.

Versions of debusine and its dependencies

I was using 0.6.0 of the debusine client.