test(frost): cover the batch's failure modes and its crypto without a database

Phase 6 of docs/frost-batch-signing.md. 361 jvmTest and 227 testDebugUnitTest
pass.

## Inbound path (SignedGroupKeyStateTest)

Both drive the manager with a hand-built inner event rather than one the other
device queued, which is the only way to be a faulty or dishonest member in this
harness.

- A one-value nonce offered for a three-item batch does not count towards the
  threshold: the coordinator never reaches a signer set. The length check is all
  that stands between a batch and a signer whose contribution lines up against
  the wrong messages, so truncating or padding would produce partial signatures
  aggregated against events nobody agreed to. The test then pumps the real nonce
  and the batch completes -- it is a stall, not damage, which is
  FrostSignerMessage's composite key doing its job.
- A second proposal under the session's own id changes neither its event ids nor
  its seeds. Every seed is already committed to its item's message; a different
  batch under the same id would have those seeds produce a second partial
  signature over a second message, which is how a share is extracted.

## Real FROST, no database (FrostSigningRoundTest)

- A k=3 batch from one signer set, all three verifying against the room's key --
  the manager's shape with the database taken out of the way.
- Item 0's signature does not verify against item 1. Signing three events in
  lockstep must not make any of them interchangeable.
- Both halves of the no-shared-nonce property, because either alone is enough to
  be relied on by accident: SecretNonce.generate mixes the message in, so one
  seed under two messages already gives two nonces -- and the manager mints
  distinct seeds regardless.

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

docs/frost-batch-signing.md

@@ -423,14 +423,28 @@ sharing costs is the secret share, to anyone who sees both partial signatures.
 It is the cheapest possible guard against the one mistake in this document that
 loses the key, and it catches an index bug nothing else here would.
 
-Then, still to write:
+Then two on the inbound path, driven by handing the manager a hand-built inner
+event rather than one the other device queued — which is the only way to be a
+faulty or dishonest member in this harness:
 
-- a wrong-length payload is dropped rather than truncated;
-- a second proposal under the same session id with a changed item is ignored;
-- a `k = 3` batch in
-  [FrostSigningRoundTest](../composeApp/src/commonTest/kotlin/press/mantra/compose/managers/FrostSigningRoundTest.kt),
-  against real FROST and no database, for the same reason that file exists at
-  all: the library calls are checked without a database in the way.
+- **a wrong-length payload is left out, not truncated.** The length check is all
+  that stands between a batch and a signer whose contribution lines up against
+  the wrong messages. Assert that a one-value nonce for a three-item batch does
+  not count towards the threshold — and then that the real nonce replaces it and
+  the batch finishes, so it is a stall rather than damage.
+- **a second proposal under the same id changes nothing.** Every item's seed is
+  already committed to that item's message; a different batch under the same id
+  would have those seeds produce a second partial signature over a second
+  message.
+
+And three in
+[FrostSigningRoundTest](../composeApp/src/commonTest/kotlin/press/mantra/compose/managers/FrostSigningRoundTest.kt),
+against real FROST with no database, for the same reason that file exists at
+all — the library calls are checked with nothing in the way: a `k = 3` batch
+from one signer set where all three verify, an item's signature refusing to
+verify against its neighbour, and both halves of the no-shared-nonce property
+(one seed under two messages gives two nonces, *and* the seeds differ anyway —
+either alone is enough to be relied on by accident).
 
 ---