`incorrect-architect` rejects any address whose TLD is longer than four characters

incorrect-architect caps the top-level domain of the address at four characters, so an address on any longer TLD is reported as malformed.

src/main/resources/org/eolang/lints/metas/incorrect-architect.xsl:16:

<xsl:if test="$meta-head='architect' and not(matches(upper-case($meta-tail),'^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$'))">

[A-Z]{2,4} is the whole story: a TLD of five characters or more never matches, and the meta is reported with

The format of the +architect meta is wrong: ... (an email expected instead)

Delegated TLDs longer than four characters have been ordinary for a decade — .online, .software, .email, .company, .systems, .technology, .dev is fine but .developer is not.

Verified as two packs under incorrect-architect, each with defects: 0, both failing on master:

Tests run: 490, Failures: 2

while good-architect.yaml beside them keeps passing.

Root cause

The pattern is one of the well-known "good enough" email regexes from the era when four characters was the longest TLD in use. Nothing else in the rule constrains the domain, so the length limit is doing all of the rejecting.

Suggested fix

Drop the upper bound, which is the part that has gone stale:

'^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$'

That keeps every address the rule accepts today and stops refusing the ones above. If the intent is only to catch a value that is obviously not an address — a URL, a name, an empty tail — then requiring an @ with something on each side of it says that much without a guess about the domain.