.tj zone has no standard WHOIS server (port 43) — only a web CGI endpoint

[bycorp]

Title: .tj zone has no standard WHOIS server (port 43) — only a web CGI endpoint

Body:

The .tj (Tajikistan) TLD does not have a standard WHOIS server reachable on
port 43. whois.nic.tj does not resolve in DNS (confirmed via getaddrinfo),
and there is no entry for .tj in module.tld.servers.json, which currently
causes a ServerMismatchException ("TLD server not found in current server
hosts") for any .tj domain lookup.

The registry (nic.tj) only exposes a web-based CGI whois interface:

http://www.nic.tj/cgi/whois2?<domain-name-without-tld>

This endpoint has two distinct response shapes depending on whether the
domain is registered, confirmed by direct testing:

Registered domain (example: google.tj) — UTF-8 HTML page containing a
data table, with a row like:

<td class="field">domain name</td><td>google.tj</td>

Unregistered domain — a much simpler windows-1251-encoded HTML page with
no table at all, just:

<p>
EXAMPLE.TJ - no records found
</p>

Note the character encoding also differs between the two response shapes
(UTF-8 vs windows-1251), which any parser would need to account for.

Since this library's TldServer / SocketLoader model assumes a raw
WHOIS-protocol server (host:43), there's no way to represent .tj correctly
in module.tld.servers.json today — neither the server itself nor the
response format fit the existing assumptions.

Would it be reasonable to support an HTTP-based lookup type for zones like
this (some other ccTLDs likely have the same limitation), e.g. by allowing a
TldServer entry to specify an HTTP endpoint and using
CurlLoader/file_get_contents instead of a socket connection, plus a way
for a custom parser to handle non-standard response formats (including
mixed character encodings)? Happy to help test if there's an existing
extension point I missed, or to submit a PR if you can point me to the right
approach.