build-in-devcontainer: fail if expected devcontainer directories aren't found

[jameslamb]

Follow-up from #408 (comment)

As of this PR, if the build-in-devcontainer workflow is called and the calling repo is missing the expected devcontainers directory, it'll fail loudly instead of passing silently.

Notes for Reviewers

The extra flexibility here bit us during rapidsai/build-planning#236. In the first round of PRs there, RAPIDS devcontainer directories were renamed from like cuda13.0-pip to cuda13.1-pip but the corresponding call of this workflow wasn't updated. The devcontainer CI jobs passed in CI and we didn't notice that builds were not actually running.

As of this PR, they'd fail loudly and alert us to that.

[rockhowse]

I don't 100% fully comprehend the world of devcontainers yet and defer the actually ✅ to someone more knowledgeable like @trxcllnt

Once someone with more devcontainer related 👀 feel free to ping me and I am happy to ✅ as I in-general support fail fast and loud for critical things that were currently failing silently causing confusion and engineering time trying to track down.

[gforsyth]

These devcontainer workflows were passing in a newer (private) repo even though there are no devcontainers set up for that repo. These changes would make those workflows fail in that scenario. I think that's fine -- probably best to not add the devcontainer workflow unless you want it to do something.

[jameslamb]

That's my perspective too. The solution for not having devcontainers yet should just be "don't run the devcontainer CI job" just as a repo that only has conda packages wouldn't call any of the wheels workflows.

I think being stricter here is worthwhile.