`+unlint` fails to warn when given invalid values, leading to silent suppression failures

Problem

Malformed +unlint values such as +unlint foo:abc or +unlint foo: (empty line part) are silently ignored: the lint neither suppresses anything nor warns about the bad format, so a user typo quietly disables an intended suppression.

Root cause

src/main/java/org/eolang/lints/LtUnlint.java:62-72 parses the +unlint tail into three buckets (global, single/range via regex, and granular):

final boolean global = !unlint.matches(UNLINT_LINE_REGEX);
...
final boolean granular = ... starts-with(tail, name + ":") ...

A tail like foo:abc or foo: matches the granular predicate but none of the three regex branches, so it falls through with no effect. LtIncorrectUnlint validates only the name part (up to :), not the format after it.

Minimal example

+package x
+architect yegor@256.com
+version 0.0.1
+home https://github.com/objectionary
+spdx SPDX-FileCopyrightText: Copyright (c) 2026 Objectionary.com
+spdx SPDX-License-Identifier: MIT
+unlint ascii-only:abc

[] > main
  # Привет
  42 > @

The ascii-only defect is NOT suppressed (fine), but the user is never told that ascii-only:abc is an invalid format — the suppression silently does nothing.

Expected behavior

A +unlint with an invalid line/range part should produce a warning (either from LtUnlint or from LtIncorrectUnlint), so the user learns about the typo.

Related

• LtIncorrectUnlint.java — currently validates only the lint name.
• The +unlint format is parsed independently in three places (LtUnlint, DefectMissing, UnlintInRange) — a shared parser would make validation consistent.

Start in src/main/java/org/eolang/lints/LtUnlint.java:62-72 and compare how malformed tails are classified. Review LtIncorrectUnlint, DefectMissing, and UnlintInRange, which independently parse +unlint values. Done means invalid line or range parts such as foo:abc and foo: produce a warning instead of being silently ignored.