buf curl: extra-message check masks JSON errors and calls server-streaming methods "a unary RPC"

[fchimpan]

Summary

Two defects in the "input contained more than one request message" check in the buf curl invokers:

1. handleServerStream copy-pastes the unary wording: sending two request messages to a server-streaming method reports method X is a unary RPC, but input contained more than one request message — actively misleading for a streaming method.
2. Both handleUnary and handleServerStream gate on err != io.EOF, so a real JSON syntax error in the trailing data is swallowed into the same "more than one request message" text instead of surfacing the JSON error and offset.

Reproduction

# 1. wrong wording (server-streaming method):
buf curl --schema x.proto -d '{"a":1} {"a":2}' https://host/pkg.Svc/SomeServerStreamMethod
# -> "method ... is a unary RPC, but input contained more than one request message"

# 2. masked JSON error (any unary/server-stream method):
buf curl --schema x.proto -d '{"a":1} garbage' https://host/pkg.Svc/SomeMethod
# -> same "more than one request message" text; the JSON syntax error is hidden

Root cause

private/buf/bufcurl/invoker.go:129-131 (handleUnary) and :185-187 (handleServerStream) — two identical blocks:

if err := provider.next(dummy); err != io.EOF {
	return fmt.Errorf("method %s is a unary RPC, but input contained more than one request message", inv.md.Name())
}

The second block sits inside handleServerStream (wrong wording), and neither block distinguishes "successfully decoded a second message" (err == nil) from "trailing data failed to parse" (err != nil && err != io.EOF).

---

Found via a full mutest (mutation-testing) run over this repo; verified by source inspection (enclosing functions confirmed).