`unsorted-metas` fails to report out-of-order meta if it's alphabetically above first meta

unsorted-metas compares every meta with the first meta of the file rather than with the one immediately above it, so a meta that is out of order with respect to its neighbour, but still above the first one alphabetically, is never reported.

src/main/resources/org/eolang/lints/metas/unsorted-metas.xsl:13-17:

<xsl:for-each select="/object/metas/meta">
  <xsl:variable name="meta-text" select="concat(head, ' ', tail)"/>
  <xsl:variable name="previous" select="(preceding-sibling::meta)[1]"/>
  <xsl:variable name="previous-text" select="concat($previous/head/text(), ' ', $previous/tail/text())"/>
  <xsl:if test="$meta-text &lt; $previous-text">

preceding-sibling is a reverse axis, so preceding-sibling::meta[1] is the nearest preceding meta — but the parentheses in (preceding-sibling::meta)[1] turn the axis result into a sequence in document order first, and [1] then picks its first item: the file's first meta. Every meta is therefore checked against the same one.

This file is reported clean:

+architect yegor256@gmail.com
+version 0.0.0
+home https://github.com/objectionary/eo

[] > foo
  42 > @

home sits after version, which is the exact thing the rule is for. Verified as a pack under unsorted-metas with defects: 0, which passes on master:

Tests run: 489, Failures: 0

The two catches-* packs beside it keep passing because in both of them the out-of-order meta is out of order against the first meta as well — catches-metas-unsorted.yaml has +alias stdout … followed by +alias stdin …, and catches-many-unsorted-metas.yaml starts with +z, above which everything else compares low. So the suite never exercises the case the parentheses break.

Suggested fix

Drop the parentheses, so the reverse axis keeps its meaning:

<xsl:variable name="previous" select="preceding-sibling::meta[1]"/>

With that, the file above is reported at the +home line, and the two existing packs keep their current defects.

A pack for the neighbour case is worth adding in the same change — three metas where the third is out of order with the second but above the first — since that is exactly what the suite cannot see today.

Start with src/main/resources/org/eolang/lints/metas/unsorted-metas.xsl:13-17 and inspect the existing unsorted-metas packs beside it. Verify the neighbour-order case described in the issue, then run the test suite and add a pack covering three metas where the third is out of order with the second but above the first.