The only obligation any maintainer has is to abide by whatever terms they release their code under. I don’t think it’s reasonable to expect professional support from any project maintained by a single individual.
Hurting others (which, to be clear, I'm not claiming has happened here) is pretty easy to do. For instance, someone opens a request, you say "Patches welcome," they spend time writing a long implementation, and you say "Never mind, I don't like this feature." You're wasting their time, and had you just not said anything, they would have been in a better place. Writing software with backdoors, or recklessly writing software in a way that makes it prone to vulnerabilities, also hurts people.
Impeding others is a softer form of this. There isn't the ability for five hundred Python dependency management projects to all exist and be successful. If you get your project listed as the standard recommendation https://packaging.python.org/guides/tool-recommendations/ , you are effectively promising that it is suitable for people who need a tool like it, and in turn that you have both the willingness and time to make it happen. You don't have to get it so listed. (You can also, of course, change your mind and de-list it.) You can absolutely say, this is a project for my own needs and I don't want to accept support requests at all. Then, at least, someone else can create a similar tool - either their own, or based on your open-source code (and abiding by your license). But if you're signed up to be the standard tool, you're impeding others who actually do have the time and bandwidth for improvements and would be willing to make a competing tool if you're not able to stand by your commitments.
If as you say, somebody released code saying that it was something they were willing to support, it’s reasonable to expect said author to stand by their statements.
That said, this seems like it would be a more implicit expectation than an explicit agreement in many cases. How could a community enforce good behavior in this regard?
Going by your previous example, would it be reasonable for the recommended list of libraries to be more carefully curated for people on such a way that only stable _and_ well supported libraries are put forward? Putting hard requirements on official recommendations seems like it’s be a fairly simple way to avoid such situations.
That's not actually true, right? The obligation flows the other direction. People who receive the code are obligated to abide by the terms. The author does not have to do anything except follow the law. They are not bound by the terms under which they are distributing their code.