Add missing public API research commands

[gulshngill]

Summary

• expose eight public API endpoints as direct nansen research subcommands
• document command options and endpoint-specific constraints in the CLI schema and README
• add mocked exact-path/request-shape coverage and refresh the endpoint inventory

Validation

• npm test -- --reporter=dot — 2,571 passed, 2 skipped
• npm run lint
• git diff --check

[nansen-pr-reviewer]

pr-reviewer Summary for #d20cff2

📝 2 findings

Review completed. Please address the findings below.

Findings by Severity

Severity	Count
🟡 Medium	1
🔵 Low	1

Review effort: 3/5 (Moderate)

Summary

This PR cleanly exposes eight new public API endpoints as nansen research subcommands. The implementation follows existing patterns throughout — consistent use of requireOptions, buildPagination, parseTimeframeDays, parseSort, mocked unit tests, and schema.json updates. Changeset semver (minor) is correct. Two issues worth addressing:

Findings

src/commands/research.js — Medium

historical-token-ohlcv mutual-exclusivity guard fires with a misleading error when neither anchor is omitted

The check on line 315 is:

if (Boolean(asOfDate) === Boolean(asOfTs)) {
  throw new NansenError('Provide exactly one of --as-of-date or --as-of-ts', ...);
}

When neither --as-of-date nor --as-of-ts is supplied, both are undefined, so Boolean(undefined) === Boolean(undefined) is true and the guard fires. The user sees "Provide exactly one of --as-of-date or --as-of-ts" rather than "one of --as-of-date or --as-of-ts is required". The test at line 210 only covers the "both provided" path.

Suggested fix: split the check:

if (!asOfDate && !asOfTs) {
  throw new NansenError('Provide one of --as-of-date or --as-of-ts', ErrorCode.MISSING_PARAM);
}
if (asOfDate && asOfTs) {
  throw new NansenError('--as-of-date and --as-of-ts are mutually exclusive', ErrorCode.INVALID_PARAMS);
}

Also add a test case for the "neither provided" path.

---

src/commands/research.js — Low

PUBLIC_API_SUBCOMMANDS is missing historical-token-ohlcv

historical-token-ohlcv lives in HISTORICAL_SUBCOMMANDS and is handled by its own if block before the rangeTokenHandlers dispatch table — functionally correct. However the new PUBLIC_API_SUBCOMMANDS array contains only 7 items while 8 are described as "public API" in the PR description. The naming is slightly misleading since historical-token-ohlcv is a new public API endpoint. This is cosmetic, but if a future reviewer needs to know "which new endpoints came from the public API docs", the grouping is subtly wrong.

If the split is intentional (historical anchor semantics belong with the other historical-* commands), a brief comment explaining the choice would prevent confusion.

---

Token usage: 4,716 input, 8,580 output, 1,301,106 cache read, 47,230 cache write | Usage Guide

New pushes are reviewed automatically with a 10-minute cooldown between reviews. To request a review at any time, comment @nansen-pr-reviewer re-review.