test(#1021): cover incorrect-unlint with a real lint name and line suffix

[yegor256]

Summary

LtIncorrectUnlint reports "Suppressing ... does not make sense" for
+unlint many-void-attributes:37-style suppressions of a real lint,
because it looks up the lint name after stripping the :line suffix.

Looking at src/main/java/org/eolang/lints/LtIncorrectUnlint.java on
master, this is already correct: nameOf() splits the tail on :
before checking membership in the known-lints set, and
LtIncorrectUnlintTest#understandsUnlintsWithLineNumber already covers
the shape generically. That fix landed as a side effect of PR #1404
(closing #1388), which rewrote this class, but #1021 itself was never
closed and had no coverage using an actual registered lint name run
through the production pack pipeline (the exact way the originally
reported eo-maven-plugin:lint failure on win32.eo exercised it).

This PR adds that missing integration-level regression pack, using the
real many-void-attributes lint name with a line suffix, asserting
zero defects — so this exact scenario can never silently regress again.

Test plan

• mvn test -Dtest=LtByXslTest,LtIncorrectUnlintTest passes locally, including the new pack packs/single/incorrect-unlint/allows-real-lint-with-line-suffix.yaml
• CI green

Closes #1021

🤖 Generated with Claude Code

https://claude.ai/code/session_011JuFSRNk5QvWp5dnwsqPyW

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[zaguzovmaksim0-hue]

I checked the current implementation and the regression scope. LtIncorrectUnlint.nameOf() already strips the :line suffix before membership validation, and invalid() explicitly accepts both name:N and name:N-M, so the reported many-void-attributes:37 shape is valid on current master.

The value of this PR is therefore the production-pack regression: it uses the real registered lint name instead of a synthetic name and runs through the same pack machinery that originally exposed the problem. That is the right way to pin the now-correct behavior without changing implementation code.

All current CI checks are green across Linux, macOS, and Windows. No correctness issue found. Approving.

[0crat]

@zaguzovmaksim0-hue Thanks for the review! You've earned +4 points for this: +12 as a basis; -8 for absolutely no comments posted; -4 for too few (12) hits-of-code; +4 to give you at least something. Your running score is +148; don't forget to check your Zerocracy account too).