Support the full v1 API through the generated API client #118

Why

The CLI has useful notes and folders commands, but adding a dedicated command for every v1 endpoint would duplicate the API client and leave coverage gaps.

Design

Keep all existing commands and add one generic api entry:

• api operations and api describe <OperationId> read the installed API client registry offline. They do not claim that a connected EE server supports every operation.
• api call <OperationId> delegates to @hackmd/api/raw, using the existing token and endpoint settings. Accept explicit --path, --query, --header, JSON --body, and multipart --file options.
• Print the response body by default; --include also shows status and headers. Handle empty responses, 207, NDJSON, and HTTP errors. Do not automatically retry writes.

This follows the GitHub CLI gh api design: dedicated commands for common workflows, plus a generic API entry for broader coverage. We borrow the interface idea, but delegate requests to the API client rather than adding another HTTP transport.

Generate the operation registry from the API client's vendored OpenAPI spec. Do not download a spec at CLI runtime or add another HTTP transport.

Example

# GitHub CLI: a focused command and a generic API entry
gh issue list --repo OWNER/REPO
gh api repos/OWNER/REPO/issues --include

# HackMD CLI: the same two-layer idea
hackmd-cli notes --noteId=abc
hackmd-cli api describe GetNote
hackmd-cli api call GetNote --path noteId=abc --include

Before release

This depends on the HackMD OpenAPI update and the API client PR. Publish a new API client version with /raw and the registry, then pin it in the CLI.

Reference

hmd is another reference for operation discovery and generic HackMD API commands. It reads OpenAPI at runtime; our CLI instead uses the installed API client's generated registry and raw operations.