fix(virgool): re-enable virgool.io with profile-page message check (handle JS-cookie wall)

[CasperCodes-CPU]

Re-enable Virgool with a JS-cookie-aware site check

Context

Virgool (virgool.io, Persian blogging platform) is currently disabled: true on
main with a status_code check. The site returns HTTP 200 with the same
JS-challenge HTML for every URL — both the profile page (GET /@{username})
and the previously-documented JSON API (POST /api/v1.4/auth/user-existence).
The challenge body contains a <noscript> block telling the user to enable
JavaScript so the site can set its authenticity cookies; without those cookies
every lookup looks the same regardless of whether the user exists, which is why
the prior status-code check was unreliable and the site was disabled.

Why not the POST API (PR #2311)

PR #2311 (closed) attempted to switch the entry to a POST against
/api/v1.4/auth/user-existence with presenseStrs: ['"user_exist":true']. That
endpoint is on the same origin and is gated by the same JS-cookie wall,
so it fails in exactly the same way as the GET profile URL — it just adds a
urlProbe/requestMethod/requestPayload/Content-Type to the entry without
fixing anything. Once the wall is passed (real browser cookies, residential /
Iran egress), the human-facing GET profile URL is just as good as the API.

What this PR changes

This PR restores the Virgool entry to a clean profile-page message check
that:

• Returns the right answer when the JS-cookie wall is passed (e.g. real
  browser cookies, networks that can reach Virgool from inside Iran),
• Surfaces a clear UNKNOWN (instead of mis-classifying as found / not found)
  when the wall fires, so users on geo-blocked or bare-container egress see an
  honest result.

Concretely:

• checkType: "message"
• presenseStrs: ["\"bio\""] — the bio JSON key only appears in the real
  SSR profile payload, not in the challenge HTML
• absenceStrs: ["۴۰۴"] — Persian digits for 404, shown on the
  "user not found" page
• errors: {"<noscript>": "JS-generated cookies required"} — when the JS
  challenge fires, Maigret reports a clear UNKNOWN instead of guessing
• Drop the old urlProbe, requestMethod: POST, requestPayload, and
  Content-Type header from the prior attempt — the GET URL is sufficient,
  and the POST API is behind the same wall.
• Drop disabled: true.

Diff (sites.Virgool)

 "Virgool": {
-    "disabled": true,
     "tags": [
         "blog",
         "ir"
     ],
-    "checkType": "status_code",
+    "checkType": "message",
+    "presenseStrs": [
+        "\"bio\""
+    ],
     "absenceStrs": [
         "۴۰۴"
     ],
+    "errors": {
+        "<noscript>": "JS-generated cookies required"
+    },
     "alexaRank": 37097,
     "urlMain": "https://virgool.io/",
     "url": "https://virgool.io/@{username}",
     "usernameClaimed": "blue",
     "usernameUnclaimed": "noonewouldeverusethis7"
 }

(alexaRank is unchanged from upstream and shown only as context.)

Verification

• The entry matches the shape proposed in PR fix(virgool): enable virgool.io via POST user-existence API #2311 commit 2def9a2 (without
  the unnecessary POST API plumbing) and was developed and tested against a
  local Virgool challenge response and a real blue profile payload.
• --self-check from a network that cannot pass the JS-cookie wall (most
  cloud egresses, including standard CI runners and many non-IR networks) is
  expected to report UNKNOWN for both the claimed and unclaimed names — that
  is the correct behaviour driven by the errors: {"<noscript>": ...} mapping,
  not a regression. From a network that can pass the wall, the claimed
  user blue is found via "bio" and the unclaimed name is rejected via
  ۴۰۴.

Refs: closes/supersedes #2311 (POST API approach abandoned for the reason
above).