feat: implement RPC signature verification for conveyor

[ety001]

Adds the missing verification half of the JSON-RPC auth protocol that conveyor (the Go rewrite) needs to authenticate __signed requests from JS clients.

Background

conveyor is a Steem JSON-RPC 2.0 service that must verify __signed requests signed client-side by @steemit/rpc-auth + @steemit/libcrypto. steemutil had the signing side and the right crypto primitives but 4 gaps blocked auth. This PR closes all 4.

Changes

U1 — rpc.VerifySignedRpc (core)

New exported verifier mirroring @steemit/koa-jsonrpc's verifier (src/auth.ts:65-98) byte-for-byte, including order and exact wording of all error messages. Introduces AccountFetcher, AccountPostingAuth, KeyAuth so the chain-access mechanism is injected by the caller (conveyor uses steemgosdk get_accounts), not hard-coded. conveyor wires it as:

rpc.Validate(req, func(msg, sigs, acct) error { return rpc.VerifySignedRpc(msg, sigs, acct, myFetcher) })

U2 — wif compact signature helpers

DsteemSigToBtcec / BtcecSigToDsteem validate a 65-byte compact signature has byte0 ∈ [31, 35) and return it unchanged. The dsteem/libcrypto layout (recovery+31) and the btcec/decred layout (27+recoveryCode+4 for compressed keys) are byte-for-byte identical, so no offset arithmetic is applied. (VerifySignedRpc runs signatures through this before recovery.)

U3 — fix rpc.hashMessage nonce placement ⚠️ behavior change

The nonce was written into the inner (first) hash, diverging from @steemit/rpc-auth, which puts it in the outer (second) hash. Without this fix, Go could never verify a JS-signed request. Confirmed by byte-level comparison against the JS implementation:

JS rpc-auth      : 007310ac792eba274e44d1d26dda66be822df54ce0297074e0bf8e90528eadda
Go (before, BUG) : d62d5555ca4680bf7fd4bc51140f3fb10bc1e89f9732925fc5d4b23b24d6cc7e
Go (after)       : 007310ac792eba274e44d1d26dda66be822df54ce0297074e0bf8e90528eadda  ✅

This changes Sign's output. The prior digest was wrong (unverifiable against JS), so no correct consumer depends on it.

U4 — protocol/api chain types

ExtendedAccount, FollowCountReturn, FollowReturn, OrderBook, OrderPrice, FeedHistory for deserializing condenser_api / database_api responses. KeyAuth handles the nested-array key_auths wire format ([["STMxxx", 1], ...]) via a custom unmarshaler; reputation is kept as json.RawMessage to tolerate both string and number encodings.

Cross-language verification ✅

A signature produced by @steemit/libcrypto's signRecoverably (real signing implementation) is recovered to the correct public key by the Go path:

JS sign → Go DsteemSigToBtcec → RecoverPublicKeyFromSignature → STM7jNh5...  MATCH

This vector is fixed in TestVerifySignedRpc_JSVector.

Two corrections vs. the original task spec

During implementation, source-level + byte-level analysis against the authoritative JS implementations surfaced two errors in the task spec, both confirmed with the maintainer before proceeding:

1. U3 — spec said "code is correct, only fix the comment"; analysis proved the code is wrong (nonce placement), so the logic was fixed.
2. U2 — spec prescribed a +4 offset conversion; analysis proved the layouts are already identical, and the +4 would have made RecoverCompact reject valid signatures (byte0 < 27). Implemented as a validating identity transform instead.

Tests

• go build ./... && go vet ./... && go test ./... all green (incl. -race, -count=1)
• New tests cover every acceptance criterion: JS-vector verification, byte-tamper rejection, multi-key/multisig/weight/not-found/account-length errors (exact strings), round-trip conversion, wire-format deserialization.