DDSIRTP26 — HEARTBEAT validity: the DDSIRTP25-11 resolution inverted a correct GroupInfo condition

8.3.8.6 defines currentGSN as "the last (highest) group sequence number written by any DataWriter in the
Writer's Group at the time that the HeartBeat was sent", and lastGSN as "the group sequence number
corresponding to the sample identified by sequence number lastSN". By these definitions
currentGSN >= lastGSN always holds, and currentGSN > lastGSN is the normal case as soon as another writer of
the group has written after this writer.

The 2.5 Validity list declares the HeartBeat invalid when "currentGSN.value > lastGSN.value". This rejects
legitimate HeartBeats. Example: writers A and B in one group; A writes GSN 1..3, B writes GSN 4..5; A's
HeartBeat carries currentGSN=5, firstGSN=1, lastGSN=3 and is invalid under 2.5.

It also defeats 8.7.5, whose commit rule relies on exactly such a HeartBeat: "Heartbeat.currentGSN.value >= GSN
and GSN-1 not in [Heartbeat.firstGSN.value, Heartbeat.lastGSN.value]", which requires currentGSN > lastGSN
whenever GSN-1 > lastGSN.

DDSI-RTPS 2.3 had "currentGSN.value < lastGSN.value", which rejects only the impossible case. Issue
DDSIRTP25-11 ("currentGSN.value < lastGSN.value condition seems wrong") changed it to ">" in 2.5.

Proposed resolution:
1. In 8.3.8.6 Validity, restore "currentGSN.value < lastGSN.value" and state the invariant
currentGSN.value >= lastGSN.value.
2. Clarify firstGSN/lastGSN when the writer's history is empty (lastSN = firstSN - 1: there is no sample
"identified by firstSN"), and check that "currentGSN.value < firstGSN.value" cannot reject the HeartBeat
of a writer with an empty history.