fix(mpp): stop BodyDigest panicking on JSON-marshallable body types

[ygd58]

What

toBytes in pkg/mpp/digest.go only recognized []byte, string, and the exact type map[string]any. Every other value — a decoded slice, a typed struct, json.RawMessage, a bare scalar — fell into the default case and panicked. server.VerifyOrChallenge calls BodyDigest.Compute on whatever the application passes as the request body, so a handler that decoded JSON into anything other than map[string]any could crash the process while setting up a payment challenge.

Reproduces on main:

mpp.BodyDigest.Compute([]int{1, 2, 3})              // panics
mpp.BodyDigest.Compute(json.RawMessage(`{"items":[1,2,3]}`)) // panics

Fix

BodyDigest's exported signature (body any) already promises to accept arbitrary bodies, so this routes the default case through json.Marshal instead of rejecting it — the same path map[string]any already used. Added an explicit json.RawMessage case so raw pre-encoded JSON round-trips without a redundant marshal.

The remaining panic path is narrowed to genuinely non-JSON-serializable Go values (chan, func, unsupported cyclic structures) — values no ordinary request-body decoding can produce, so it stays a programmer-error signal rather than something reachable from request handling.

No exported signature change — BodyDigest.Compute/Verify keep the same func(body any) string / func(digest string, body any) bool shape, so this doesn't affect existing callers. This answers the issue's option 1 (accept JSON-marshallable values through the existing digest path) without the breaking API change option 2 would need.

Testing

Added regression coverage in digest_test.go for slice, struct, json.RawMessage, and bare int bodies (all previously panicking), plus a test confirming a truly unsupported type (chan) still panics as expected.

go test ./pkg/mpp/... -run TestBodyDigest -v

All pass, including the pre-existing map/string/bytes cases (no regression). Also ran the full ./pkg/mpp/... suite and go vet ./pkg/mpp/... clean.

Note: the module's go.mod currently requires Go >= 1.26, which wasn't available in my build environment (newest apt package was 1.23), so I temporarily lowered the local go directive plus a gopkg.in/yaml.v3 replace to fetch test-only deps, verified everything, then reverted both before this commit — neither shows up in the diff. Happy to re-verify against 1.26 if there's a way to point me at it, or if CI just confirms directly.

Fixes #95