Answer a REPE request whose body is empty

[stephenberry]

Found while reviewing #2738. A non-notify REPE request with an empty body to a parameterized function endpoint gets no response at all — the client waits on a reply that is never sent.

param fn, empty body,  non-notify: response bytes = 0     <- hangs the client
param fn, good body,   non-notify: response bytes = 50
value,    empty body,  non-notify: response bytes = 50

This is the failure mode #2732 set out to remove, still reachable on one endpoint kind.

Why only that endpoint

read_params reported an empty body by returning false without writing anything. Every caller is told the error response is written whenever it returns false, and every registered endpoint returns immediately on it, so nothing else wrote one either.

Most endpoints never reach it — they guard on state.has_body() and skip the read (repe_registry_impl.hpp:29, :107, :130). A parameterized function endpoint can't, since it has nothing to call its function with otherwise, so it reads unconditionally (:77). That is the one path where an empty body reaches read_params.

An empty body now answers no_read_input, which is what a whitespace-only body has always answered.

The other half: notifications

Fixing only that would have made things worse in the opposite direction, so this covers both.

A notification is a request the sender has said it will not read a reply to, and the registry is careful about that everywhere else — an unknown method in a notification is silently ignored (registry.hpp:455). But read_params wrote a full error response for a notification with a malformed body, so a client that sent one got an answer it was never going to read. A failed read of a notification is now reported by not answering it, exactly as a successful one is.

Both overloads, since a custom call handler reaches the state_view one directly.

Tests

registry_view_test: an empty body to a param function is answered with no_read_input; a good body still runs the function; a notification is not answered for an empty, malformed, or non-JSON body.

Full suite 108/108 — nothing depended on notifications receiving error responses.

Note for #2738: its wording says the error response is written "on a parse failure", which was precise because of this bug. Once this lands that can be simplified to "on failure".