fix: avoid false CLAIMED for message-type sites on server errors

[ardittirana]

Summary

For message-type detection, Sherlock concluded a username was Claimed whenever the configured errorMsg was absent from the response body, without checking the HTTP status. When a site endpoint intermittently returns a 5xx, the error body does not contain errorMsg, so the username was reported as a false positive (Claimed).

This is the general cause behind #2950 (minds), and it affects any message-type site during a server error.

What changed

The message-type decision is extracted into check_message_query_status, which returns AVAILABLE when the not-found message is present, UNKNOWN on a 5xx response (the body cannot be trusted), and CLAIMED otherwise. The status_code and response_url branches already gate on HTTP status; this brings message in line with them.

Tests

Added offline unit tests in tests/test_message_query_status.py for the available, claimed, server-error, and list-of-messages cases. The server-error test reproduces the false positive on current code and passes with this change. Full offline suite (-m "not online") passes.

Closes #2950

[ardittirana]

Since the upstream 5xx in #2950 is intermittent and hard to reproduce on demand, here is a deterministic way to confirm the behavior change without waiting for a real outage. It exercises the extracted decision directly:

from sherlock_project.sherlock import check_message_query_status

# "not found" signal present -> username is available
print(check_message_query_status('{"valid":true}', '"valid":true', 200))   # Available
# signal absent on a real 200 -> claimed (unchanged behavior)
print(check_message_query_status('{"status":"success"}', '"valid":true', 200))  # Claimed
# signal absent because the server errored (502) -> previously Claimed (false positive), now Unknown
print(check_message_query_status('Bad Gateway', '"valid":true', 502))      # Unknown

On master the third line resolves to Claimed; with this change it resolves to Unknown. The non-5xx paths are unchanged, so existing message-type sites behave exactly as before. This is the case the new offline test in tests/test_message_query_status.py locks in, so the regression cannot silently return.

Happy to gate on all non-2xx instead of only 5xx if you'd prefer a stricter rule; I kept it to server errors to stay conservative and match the report.