Map Postman validity check 401s to inactive only on the vendor verdict

What does this MR do and why?

The Postman validity check client mapped every 401 response to "inactive" without inspecting the response body. Any intermediary that answers 401 -- an API gateway, bot mitigation, or an egress-level block -- was silently treated the same as a real revoked-key response, marking live credentials as revoked. This is the same class of failure that misreported GCP API keys as inactive via blanket tokeninfo 400 mapping (#588454). Under the validity check guardrail, "inactive" must mean verified revoked.

With this MR, a 401 maps to inactive only when the body is Postman's own invalid-key verdict: a JSON body whose error.name is AuthenticationError (see the Postman API documentation). Any other 401 -- a different JSON shape, or a non-JSON block page -- resolves to unknown. The JSON-but-different case logs a structured warning so interference becomes visible in logs instead of masquerading as revocations.

Behavior is unchanged for genuine invalid keys: the live endpoint answers exactly this AuthenticationError body for a bad key (verified by probing https://api.getpostman.com/me).

How to set up and validate locally

Generate a throwaway Postman API key and probe the endpoint:

curl -H "X-API-Key: YOUR_API_KEY" "https://api.getpostman.com/me"

Expected results:

• A fresh, valid key returns 200.
• A garbage PMAK-shaped key returns 401 with the AuthenticationError body.

Closes #628144 (closed). Related to the validity checks revamp epic.

MR acceptance checklist

I have evaluated this MR against the MR acceptance checklist.