`unlint-non-existing-defect` excessively re-runs XSL transformations, causing major performance issue

Problem

unlint-non-existing-defect is by far the slowest lint (14513 ms on the XXL benchmark, ~10x the next one), because it re-runs every lint's XSL transformation for every +unlint name instead of reusing the defects already computed by the main pass.

Root cause

src/main/java/org/eolang/lints/LtUnlintNonExistingDefect.java:114-123:

private Set<String> existing(final String name) {
    return this.lints.stream()
        .filter(l -> l.name().equals(name))
        .flatMap(l -> l.defects(this.xml).stream())   // raw lint, no cache
        .map(Defect::line)
        ...
}

existing() calls lint.defects(xmir) on the raw lints (not wrapped in LtDfSticky), so for every +unlint foo the full XSL transformation for foo runs again — duplicating the work already done in the main pipeline where the same lint is wrapped in LtDfSticky. The results are thrown away right after the DefectMissing check.

Expected behavior

Reuse the defects from the main pass (or share the LtDfSticky-wrapped instances), so +unlint validation does not double the XSL workload. Estimated impact: the XXL timing should drop to the same order as the other lints.

Related

• PkMono.java — where lints get their LtUnlint/LtDfSticky decorations.
• #1349 (volodya) — coverage of this lint; complementary.
• README benchmark table shows the current 14513 ms figure.

Start with src/main/java/org/eolang/lints/LtUnlintNonExistingDefect.java:114-123 and inspect PkMono.java to understand the LtUnlint and LtDfSticky decorations. Use the #1349 coverage and README XXL benchmark as validation points; done means +unlint validation reuses main-pass results and the benchmark no longer shows the excessive XSL transformation time.