`LtDfSticky` cache grows infinitely due to unbounded limit and faulty equal check in key

Problem

The LtDfSticky defect cache (backed by cactoos StickyBiFunc) never evicts entries, and its key has broken equality semantics, so in a long-lived JVM the cache grows without bounds while rarely hitting.

Root cause

1. StickyBiFunc (cactoos 0.61.1) stores results in a LinkedHashMap with capacity Integer.MAX_VALUE — no eviction. Because Source.MONO is a static singleton (src/main/java/org/eolang/lints/Source.java:27-31), every XMIR document ever analyzed by the JVM stays in memory forever → OOM under batch/daemon workloads.

2. The cache key is the XML object itself. XMLDocument.equals compares by toString() (content) but hashCode is node-identity based (Node.hashCode() in jcabi-xml) — so two documents with identical content produce different hash codes, and the cache almost never hits for different Source instances, while still growing per new document.

Expected behavior

• Bound the cache (capacity or time-based eviction), or scope it per Source instance instead of a static singleton.
• Make the key content-based (hash by toString()), so identical documents share cache entries.

Related

• src/main/java/org/eolang/lints/LtDfSticky.java:38-43 — the wrapper.
• P1 (#1389) — the related unlint-non-existing-defect performance issue.

Start with src/main/java/org/eolang/lints/LtDfSticky.java:38-43 and Source.java:27-31, then inspect how cactoos StickyBiFunc stores entries and how XML equality and hashing behave. The work is done when the cache has bounded lifetime or scope and identical document content reuses entries without unbounded growth.