`redundant-object` lint rule fails to recognize object usage above its declaration level

[h1alexbel]

Take a look at this EO snippet:

# Bytes as input.
[bts] > bytes-as-input
# Read `size` amount of bytes from `bts`.
[size] > read
  ((input-block bts --).read size).self > @ # <- usage, doesn't see this

  # Bytes-as-input block.
  [data buffer] > input-block
    buffer > @
    $ > self # <- declaration, see this

Currently, redundant-object complains about self, since lint does not see the usage of it, only its declaration.

[h1alexbel]

@yegor256 looks like new bug

[yegor256]

@h1alexbel looks like a bug

[0crat]

@h1alexbel Great job reporting that new bug! As per our policy, you've earned 12 points for your keen eye. Your contribution is vital in enhancing our project's quality. Keep an eye out for anything else that doesn't look up to par, and don't hesitate to report it. Remember, each accepted bug report earns you points! Your current balance stands at +401. Keep up the excellent work! 🐛👍

[bibonix]

@yegor256 I'm planning to work on this issue. The redundant-object lint searches for usages with the regex ^ξ(?:\.ρ)*\.<name>(?:\.[\w-]+)*$ against the @base of every <o>, but a chained reference like ((input-block bts --).read size).self does not surface as a single @base="...self" token — the parser splits it across several <o> nodes, so the candidate's count stays at 1 and the lint fires. I'll trace the actual XMIR shape, add a failing test pack, then teach the lint to recognize this usage form.

[bibonix]

Submitted PR #859 with a failing regression pack (allows-self-used-via-chained-dot.yaml) and the fix in redundant-object.xsl: a second usage regex ^\.<name>(?:\.[\w-]+)*$ now recognises chained-dot references ((...).self), and the warning is suppressed when the candidate is a $-alias and at least one such usage exists. All 358 packs in LtByXslTest#testsAllLintsByEo are green; the matrix mvn/deep/reserved jobs fail with the same pre-existing flaky timeouts (MonoLintsTest#lintsProgramCorrectly, PkByXslTest#doesNotDuplicateDefectsWhenMultipleDefectsOnTheSameLine) that affect master and every recent PR — verified by re-running both tests against the unmodified master XSL (45.9s vs 45.8s with the fix), so the fix doesn't introduce them.