ownership check can be failing in a way we can't fix

Currently the crate ownership check is failing. This is because one of the crates has a missing owner, because that person hasn't been able to accept the ownership invitation.

Constraints:

• This is a normal situation, which ought not to produce an irremediable CI failure.
• However, such a situation should not last indefinitely; if it does (for whatever reason) we should probably remove the ownership, which can be done without needing acceptance
• The reasons for the lack of acceptance (often, something like "this person is on vacation") typically PII which ought not to be made public
• The fact of lack of acceptance is also PII which we probably ought not to process more widely than needed. So we ought not to commit it to our public git repo.

Conclusions:

• We need an additional input to this CI job.
• The additional input needs to be editable by roughly the same people as the Arti team.
• The additional input does not need to be public.

If we could link someone's crates.io username to their TPO gitlab account, we could check to see if their gitlab account was marked "busy". But IDK if we can get an admin to mark someone busy if they forget? And what if someone is "sort of" busy?

Or maybe we could have a separate data source, listing the names of a maintainer whose ownership status is to be ignored, and an expiry date for each one.

Perhaps we could use a gitlab CI/CD "variable"? There's a UI for editing those.

CC @nickm @trinity-1686a @gabi-250 in case you have any opinions or good ideas.

Setting the Blocker label because I think it's highly undesirable that the release technician should get into the habit of ignoring warnings from CI.