fix: archive the translation that stands, not every draft of it

Follow-up to reading the archive out of `GroupSignedEvent` rather than rebuilding
it from rows. The two sources do not hold the same thing, and one place where
they differ reaches the archive.

`ChatMessage.applyInnerEvent` supersedes a translation chunk: retranslating a
passage changes the text and so the event id, so the arm drops the row it
replaces -- newest by the timestamp the group signed at, id breaking a tie. The
record does not, and should not: a signature is the group's statement and
discarding one is not that table's business. So a passage translated three times
leaves one row and three events.

While the archive was rebuilt from rows that difference was invisible, because a
sender simply had nothing but the group's current answer to each passage. Read
from the record it is not: measured on a seeded room, one retranslation leaves
one row and puts **two** payloads in the archive, and it compounds -- every draft
a group ever signed would travel in every archive it ever sends, for as long as
the room exists.

**The rule is the applying arm's, restated rather than approximated.** An archive
that shipped one translation as current while the recipient settled on another
would have both validly signed and nothing downstream to notice they disagree, so
`currentTranslationsOnly` groups by `(translationChapterId, chunkId)` and keeps
the maximum by `(createdAt, id)` -- the same comparison, spelled the same way.

Dropping the drafts is safe precisely *because* the recipient applies that rule
too. This is not what keeps them correct; it is what stops them being sent work
they would discard on arrival.

Grouped per passage rather than per chapter, or retranslating one passage would
take every other passage's translation with it. A translation naming no passage
is left alone rather than lumped in with the rest: it is unappliable either way,
and letting one stand in for a whole passage would let a malformed event suppress
a good one.

Three tests, and all three fail if the filter is removed: a retranslated passage
leaves one row, two recorded events and one payload; three translations signed in
the same second settle on the same id the row keeps, which is what pins the
tiebreak to the applying arm's; and two passages each keep their own, which is
what a group-by-chapter mistake would fail.

Two documentation corrections alongside it. docs/member-archive.md said "a
retranslated passage archives once" as a property of the rows, which stopped
being true the moment the record became the source -- it now says what makes it
true again. And `GroupSignedEvent.verifies()` said a false means the row's
columns have drifted from the event they came from. That is the reading worth
acting on and it is not the only one: a room never derived from its group's key
signs as the bare threshold key rather than as its own id, so a perfectly good
event there fails and cannot be made to pass, the key it would need being absent
from the row and unreachable from one.

498 jvm tests and 297 android unit tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/member-archive.md

@@ -373,10 +373,27 @@ end: a version sits between its artifact and the chapters hanging off it, and a
 translated chunk hangs off both a source chunk and a translation chapter, so it
 really is last.
 
-**A retranslated passage archives once.** The arm that applies a translation
-chunk drops the one it supersedes -- newest by the timestamp the group signed at,
-id breaking a tie -- so a sender holds a group's current answer to each passage
-rather than its drafts, and that is what travels.
+**A retranslated passage archives once, and that stopped being free.** The arm
+that applies a translation chunk drops the row it supersedes -- newest by the
+timestamp the group signed at, id breaking a tie -- so while the archive was
+rebuilt from rows, a sender simply had nothing but the group's current answer to
+each passage and that is what travelled.
+
+Reading from `GroupSignedEvent` changed it. The record keeps every event the
+group ever signed, deliberately: a signature is the group's statement and
+discarding one is not that table's business. So a passage translated three times
+leaves one row and three events, and an unfiltered read would put every draft a
+group ever signed into every archive it ever sends, for as long as the room
+exists.
+
+`ArchiveManager.currentTranslationsOnly` is what holds the original property up.
+It restates the applying arm's rule rather than approximating it -- newest by
+signed timestamp, id breaking a tie -- because an archive that shipped one
+translation as current while the recipient settled on another would have both
+validly signed and nothing downstream to notice the disagreement. Dropping the
+drafts is safe precisely *because* the recipient applies the same rule: it is not
+what keeps them correct, only what stops them being sent work they would discard
+on arrival.
 
 ### Ordering