`excessive-visibility` lint incorrectly flags public constants in `win32`/`posix` as over-exposed

excessive-visibility decides that an attribute is over-exposed by looking only at the tests written inside the same object, so every attribute a library object publishes for other files is reported — with advice that would break the callers.

Run over the parsed XMIR of eo-runtime/src/main/eo/win32.eo (objectionary/eo at b747717325):

win32.xmir:22  warning  experimental
The method "append" is public, but no unit test refers to it; obfuscate it with >> instead of >
win32.xmir:23  warning  experimental
The method "creat" is public, but no unit test refers to it; obfuscate it with >> instead of >

and the same for posix.xmir.

Those two are not methods and they are not unused. win32.eo:22-23:

  8 > append
  256 > creat

they are the flag constants of the syscall wrapper, and the runtime reads them from other files:

eo-runtime/src/main/eo/directory.eo:70   win32.rdonly.plus win32.creat
eo-runtime/src/main/eo/file/touched.eo:76  win32.creat.plus win32.exclusive
eo-runtime/src/main/eo/posix.eo:104      posix.wronly.plus posix.append

Following the advice — renaming > creat to >> creat — gives the attribute a generated cactus name (§9.2), which is unreachable from outside the file, so all three call sites above stop compiling.

Root cause

src/main/resources/org/eolang/lints/design/excessive-visibility.xsl:22 looks for the reference inside the object's own tests:

<xsl:variable name="used" select="$tests//o[@base and matches(@base, concat('^(ξ(\.ρ)+\.|\.)', $method, '(\.|$)'))]"/>
<xsl:if test="empty($used)">

A .xmir holds one file, so "no test refers to it" is all this rule can see; a caller in another file leaves no trace in this document. The same blindness is reported for redundant-object in #1276 — there the references are Φ-rooted and simply not indexed; here the references are in another document altogether, which no indexing inside one file can fix.

The message compounds it by calling every attribute a "method": 8 > append binds a number.

Suggested fix

The check is sound for a program and unsound for a library, so it needs to know which it is looking at. Two ways:

• Report only attributes of an object that is not published — one with a +package meta is a library object by definition, and its direct attributes are its API; the rule could skip the top-level object's own attributes and keep checking the nested formations, where "used only by tests" really does mean over-exposed.
• Or gate the rule on a whole-program run: lints also has the Programs entry point that sees every XMIR of a project at once, and cross-file references are decidable there.

Whichever is chosen, the wording is worth fixing in the same change: "The method X is public" should be "The attribute X", since the rule matches every named child, and the advice obfuscate it with >> should not be given for anything reachable from outside the file.

Start with src/main/resources/org/eolang/lints/design/excessive-visibility.xsl:22 and inspect how the lints Programs entry point handles XMIR across files. Compare the win32 and posix warnings with their callers in directory.eo, file/touched.eo, and posix.eo. Done means published constants are not advised to become unreachable, and diagnostics call matched children attributes rather than methods.