feat(auth): bind request payloads into auth proofs

[kjartan221]

Summary

@bsv/auth is documented as authenticating requests, but createAuthProof /
verifyAuthProof only ever signed { action, identityKey, expiresAt, nonce }. There
was no way to bind a request's payload, so for any action that carries a body (e.g. a
username change → { newUsername }) the body was not covered by the signature — an
intermediary could alter it and the proof still verified. This PR closes that gap by
letting a proof optionally bind the request body, and tidies the now-too-long parameter
list into a named-args object.

What changed

• Optional request-body binding. createAuthProof and verifyAuthProof accept an
  optional body. The client signs over the auth fields plus the body bytes; the
  verifier binds the raw received body the same way. A tampered, missing, or injected
  body fails the signature check. The body is bound only — it is not added to
  proof.data and is transmitted with the request as usual.
• Canonical encoding. When a body is present it is appended length-prefixed
  (VarInt length + bytes via Utils.Writer), so arbitrary binary is unambiguous. With
  no body the signed bytes are exactly serializeAuthSigData(data) as before.
• Body normalization (normalizeBody): string → UTF-8, ArrayBuffer / typed
  array → raw bytes, plain object or any array → JSON. Binary must be passed as a typed
  array / ArrayBuffer; arrays are always treated as structured data.
• Named-args API. Both functions now take a single object (CreateAuthProofArgs /
  VerifyAuthProofArgs, both extending AuthProofOptions), matching the @bsv/sdk
  wallet-method style and removing the fragile 5-positional-arg ordering. The
  AuthProofClient / AuthProofServer wrappers take the same object minus the bound
  options.
• Perf benchmark. Opt-in npm run test:perf (dedicated jest.perf.config.js,
  excluded from the default run) measuring create/verify vs. the pure serialization
  functions.

Why

The lightweight signed-proof scheme is meant to authenticate any single request, not
just login. Authenticating the action but not the body is a real integrity gap for
any write request. Length-prefixed binding is the minimal, transport-agnostic way to
cover the payload (same approach as AuthFetch's request serialization) without
changing the proof's shape or its single-use / expiry semantics.

Why this fixes the issue

A body-bearing request signed via createAuthProof({ …, body }) and verified via
verifyAuthProof({ …, body }) now fails verification if the body differs by a single
byte — so the proof genuinely authenticates the request contents the docs promised, not
just the action. Login and other bodyless calls are unaffected.

Backward compatibility

• Omitting body produces byte-identical signed bytes to the previous version, so
  existing bodyless (login) proofs verify unchanged.
• The call signature changed from positional to a single args object
  (expectedAction → action); this is the one breaking change. Downstream callers
  were updated in tandem.

Testing

• npm test — full unit + real-ProtoWallet round-trip suite (same-body verifies;
  tampered / missing / injected / binary bodies behave correctly; login unchanged).
• npm run test:perf — confirms body binding adds ~12 µs over a ~5 ms signing op
  (≈0.2%), i.e. no measurable overhead.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud