fix(web): reject a negative-zero literal, which loses its sign when serialized

Copilot's twelfth pass. The suppressed comment is right and is fixed here; the
inline one is real too, but needs a core API change and is filed as #2171.

`-0` is represented exactly, so the digit comparison had nothing to say about
it — but `JSON.stringify` writes it as `0`, so the loss happens on the way
*out* rather than on the way in. The editor showed `-0` and the wire carried
`0`, and the viewer rewrote a received `-0` while pretty-printing.

`hasImpreciseIntegerLiteral` becomes `findUnsendableNumberLiteral`, checking
`Object.is(Number(literal), -0)` for every numeric spelling — `-0`, `-0.0`,
`-0e1` — before the integer-only digit check. Returning the offending literal
rather than a boolean lets the message name it, which is more use than either
of the two rules behind it and matches how the duplicate-key message reads.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UL9retfvAXRgvi6EWk4SY4
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/components/groups/EditReplayModal/EditReplayModal.test.tsx

@@ -218,9 +218,7 @@ describe("EditReplayModal", () => {
     renderWithMantine(<EditReplayModal {...baseProps} method="tools/call" />);
     await setAceText('{"name":"echo","arguments":{"id":9007199254740993}}');
     expect(screen.getByRole("button", { name: "Send" })).toBeDisabled();
-    expect(
-      screen.getByText(/cannot be represented exactly/),
-    ).toBeInTheDocument();
+    expect(screen.getByText(/would not arrive as written/)).toBeInTheDocument();
   });
 
   it("disables Send for a non-string prompt argument", async () => {