Generated verdict review path lists can exceed the relay request limit; compact the messages #14

Observed on 0.9.3

A normal verify operation can generate a relay message too large for the relay HTTP reader. This is not a request to increase the body limit: please make the generated message representation smaller while preserving review validity.

In an actual private board, a verification move contained 1,420 sorted unique review.paths entries. The path array alone occupied 133,993 UTF-8 JSON bytes; the complete plaintext move was 136,018 bytes, before sealing/base64 and the request envelope. The human review note was only 1,417 bytes. The relay refused it with:

[BAD_REQUEST] the body exceeds 100000 bytes; send one move or request at a time

It was already one move. That unacknowledged move became the queue head and blocked later updates and confirmed landing. No private payloads, board identifiers, credentials or repository contents are attached.

Source relationship

Pinned release: c3c21438ebda51fc410519b23cdea68801b1bb79.

• src/api-http.js: BODY_BYTES = 100_000 and aggregate request-body refusal.
• src/verdict-reviews.js: the sealed review requires a sorted, unique path array.
• src/verdict-freshness.js: those paths are used for exact changed-file membership when detecting stale verdicts.

Our installed client has local overlays, so this is not claimed as a complete vanilla end-to-end reproduction. The HTTP reader and cited path-validation/freshness relationship are present in the pinned upstream source; the payload sizes and relay refusal were observed on the actual installation.

Related but distinct: #10 addressed generated landing-header citations; this failure is the single encrypted relay verify payload and its path-coverage array.

Desired correction

Keep messages compact, rather than raise the server body limit. Possible directions are a compact/lossless path-set representation, or explicitly supported conservative directory/pattern coverage. A bare wildcard substitution is not sufficient with today's exact-membership reader and could miss changed files. Compatibility must not let an older reader silently treat compressed/pattern coverage as literal filenames and accept stale work.

Please also consider a supported recovery path for an already queued oversized verification move, preserving the original actor, candidate, verdict and ordering, rather than requiring a board reset or replaying the review.

Suggested regression: generate a review with many long paths, prove its actual sealed HTTP envelope fits, and verify that a later change to a covered file still makes the verdict stale. Include old-client/unsupported-format behavior. This suggested regression has not been run against an unmodified upstream deployment.