v0.1.2

Turn on noUnusedLocals/noUnusedParameters

Refuse a JSON-RPC response carrying both result and error

§5 makes them mutually exclusive: "Either the result member or error member
MUST be included, but both members MUST NOT be included." Such a response was
read as an error response, which is guessing at which half the sender meant.
Refused now, the way a bad jsonrpc/id envelope already was — on the single-call
path and per item in a batch.

Release 0.1.2

Check a batch envelope the way a single call is checked

call verifies the JSON-RPC version, that the id echoes the one it sent, and
that a success carries result — because a stale, mis-routed or forged
response would otherwise satisfy the wrong call. batch verified none of it:
it matched by id and read result/error straight off, so a { jsonrpc: "1.0", id: 0 } came back as { ok: true, value: undefined }.

Each item now goes through the same three checks, and two responses claiming
one id are refused rather than silently resolved to the last — keeping the
last is how a response answers a call it was not for. A null result is still a
value.

Create the GitHub release from the publish workflow

A published version arrived with no notes: npm showed a number, GitHub showed
nothing, and the only way to learn what changed was to read a diff. The commit
messages already carry the reasoning, so the release is built from the commits
the tag contains rather than written twice.

Skips a pure version bump, leaves an existing release alone, and does nothing
when the run was not built from a tag. The job takes contents:write for this;
the workflow default stays read.

---

Changes since v0.1.1.