Companion CLI replies over 175 bytes are truncated silently #3

Found while building the hw command (#1). Affects every CLI command, not just that one.

Problem

The CLI reply buffer is COMPANION_CLI_REPLY_SIZE (256) but a CMD_RUN_CLI_COMMAND response frame carries MAX_FRAME_SIZE - 1 (175), and the app protocol has no continuation for this response. A reply between those two sizes arrives missing its tail with nothing to indicate it, which reads exactly like a complete answer.

Observed on hardware over the phone-app path:

hw board
  -> board: ...
     role: companion
     reset: 0x00000000 (none reported     <- cut mid-word
                                          <- final line simply absent

A reader has no way to tell a short reply from a cut one.

Scope

Not specific to hw — any command whose output exceeds 175 bytes is affected, including the stats-core / stats-radio / stats-packets JSON.

Fix

app/CompanionMesh.cpp: the frame limit is the app protocol's and is left alone. A cut reply now ends in ... so the truncation is visible.

Paging cannot solve this, and the reason is worth recording: a command sizes its output to CLI_REPLY_SIZE and cannot see which transport will carry it. On companion firmware the USB text sideband, CMD_RUN_CLI_COMMAND and the V-Contact loopback all reach CommonCLI indistinguishably, all with sender_timestamp == 0.

Status

Fixed on work/hw-cli as aecbc42. Confirmed on hardware before and after.

A fuller fix — a continuation for this response, or a reply-size cap the command can see — would be a protocol change and is deliberately not attempted here.