test: soften membership sample check

[nightcityblade]

Solves issue #636

Changes

Makes the volatile membership sample check verify a list of candidate users and warn instead of failing when none currently match the expected live membership state.

Tests

• .venv/bin/python -m pytest tests/test_memberships.py
• .venv/bin/ruff check tests/test_memberships.py

[Boss-1s]

Maybe sort the other ones too

[faretek1]

assert sum(acc.has_ears() and acc.is_member() and acc.has_membership_badge() for acc in (sa.get_user("griffpatch"), sa.get_user("ceebee"), sa. get_user("using remember"))) > threshold

This PR reads like ai slop. While it probably works there is no doubt that your agent noticed this simply because of the 'good first issue' label. I would rather that random bots did not waste the opportunity of simpler issues which could be solved by newcomers who actually care instead of throwing an ai-drive by pull request

The best part about scratchattach as a project is to provide a compelling bridge for scratchers to enter the world of text based programming and python. By contributing to the library themselves they learn about open source, git, github, and more about python. I have been incredibly lucky to have been able to contribute to this project for the last 2 years and even though I often feel that I don't do enough for the project, I would never wish for this opportunity to be taken from potential committed contributors who could gain much experience, as I did, by helping with the project. By closing "good first issues" with ai agents, nobody learns. The PR works at best, and is AI hallucinations at worst. Nobody gains anything. Its not that hard for us existing contributors to fix this issue but there is no learning benefit on your side. You simply gave us an automated ai PR without explicit disclosure (read the contributing rules) and want us to merge it... For what? So you can add to your github statistics? So you can boast about your agent being capable of replacing the novices who maintain a silly API wrapper for a kids website? I don't think that's impressive, and I don't think that is helpful for the scratch community to grow as a whole, which is what this project wants to provide. I could write the same kind of code too-you saw it above - but at least my one had some essence of thought in it - your agent is a statistical machine which will churn out code at the average quality of all code inputted to your model. Why didn't I make the fix myself? Well I will admit that I am a lazy idiot, but I also hoped that "good first issue" could serve the actual intended purpose - to introduce first-time contributors who could later become second time contributors, and maybe later core maintainers. I expected a PR like this when I added that label. But I did it anyway. Last times I put a primitive fix in the issue description itself. The bots just copied it. And those fixes were primitive for a reason because they did not actually solve the problem in a good way.

The key benefit of a project like this, in my opinion, is not the library itself, but rather the path it provides for passionate scratchers to have a compelling reason to use more professional languages like Python. This is why we must maintain the synchronous api while just maintaining an async library would be easier. Because it would take away from the ease of use of the library and steal from the learning path of countless users who would otherwise learn, and importantly, want to learn, python. By forgetting this goal, to an extent we would be betraying the users of this library.

I'm going to close this PR because it does not even disclose the use of ai. @Boss-1s, if you make a PR I would be willing to merge it