fix(js/verify): fail clearly on non-JSON explorer responses instead of crashing

[Equious]

Problem

verify.ts's httpGet / httpPostForm call await res.json() directly:

async function httpGet(url: string) {
  const res = await fetch(url);
  return (await res.json()) as Record<string, unknown>;
}

If the explorer returns anything that isn't JSON, res.json() throws an opaque
SyntaxError: Unexpected token 'o', "no available server" is not valid JSON,
which propagates up and aborts the entire deploy/verify flow with no
indication that the explorer was at fault.

Hit live while running the hardhat-template flow during a brief explorer
outage — the gateway returned a plaintext no available server and the whole
just all died at step 1 (MockToken verification), even though the deploy
itself had succeeded.

Fix

Route both helpers through a shared readJsonResponse that checks the HTTP
status and guards JSON.parse, throwing a descriptive BattleChainError
(status + a body snippet) instead of an opaque SyntaxError. This mirrors the
resilient response handling already in query.ts (queryAgreementByContract).

No API change; build + vitest (39/39) pass.

Note for maintainers: this makes the failure legible; callers (e.g. the
starter's all.ts) may additionally want to treat verification as best-effort
so a transient explorer hiccup doesn't abort an otherwise-successful deploy.

🤖 Generated with Claude Code

[Equious]

Added a second fix to this branch: verify.ts now resolves the full vyper compiler version (X.Y.Z+commit.<hash>, no leading v) for the vyper-json path. It previously sent a bare v0.4.3, which Sourcify can't fetch ("Failed fetching vyper 0.4.3 for platform linux") — so the Vyper fallback never verified. Mirrors the battlechain-lib-py fix in #18 (confirmed live). Latent in practice since the hardhat-template verifies Solidity. build + vitest (39/39) pass.