feat!: rename commands to the naming standard (CLI-59)

[leemour]

Task

CLI-59: rename the commands to the naming standard in CONVENTIONS, "Command names". No aliases.

Why

The standard puts the resource first and gives each verb one meaning. Several names broke it: a verb used as a group (backup, export), a wire field used as an option (--cid), one command that both showed and changed a thing (chats settings), and update naming the tool itself.

What

Before	After
backup messages <chat>	store fetch <chat>. Fetches by default; --estimate only prices the work (it replaces --run). --max-pages (40) and the pause are unchanged. --pause takes a duration, parsed as --timeout is (5s, 500ms; a bare number or 0 is refused). The JSON keeps run
export messages <chat>	store export <chat>
--cid (send, forward)	--send-id. The outcome_unknown detail cid → sendId; MCP input cid → send_id
chats read	chats mark-read; MCP max_chats_read → max_chats_mark_read
chats settings	removed. chats show (and MCP max_chats_show) now carries settings, description and access (null for a dialog, offline, or a group the login did not carry); the invite link stays with chats link show. chats update takes the five --<setting> on|off flags
update [--check]	upgrade [--check], and the newer-version notice names it
recipients off	recipients clear (JSON off → cleared); bot recipients off → bot recipients clear
account sessions end-others	account sessions end --others (required for now; --yes still required)
complete hidden	shown in max --help

Decisions to review:

• --since / --last are now optional. Removing the requirement is safe. Each run is still capped by --max-pages, and the fetch already skips the stretches it holds, so a run without either continues toward the chat's start and needs no new state. A test shows it over three runs. Passing both is still refused. Without either, --estimate answers missing: null until the chat's start has been read, instead of pricing back to 1970.
• chats update --title … --all-can-pin … sends two requests. Nobody has measured one request that carries both a title and settings. If the second request fails, the title change has already landed.
• The notice text comes from cli-core, which says max update. src/update.ts rewrites that line and stays silent after upgrade. The real fix belongs in cli-core.
• An old name fails with exit 1 (commander's code for an unknown command or option). backup, export and update are now read as a profile name, so their error is "unknown command '1'" or "unknown option". Nothing is sent; a test covers every old form.
• MCP: only the renamed tool changed its name, and which tools are offered is unchanged. max_chats_show answers with the new fields.
• store and upgrade are now command words. A profile with either name is hidden behind the command, as chats would be.

The CHANGELOG lists every rename under «Изменено — может сломать скрипты».

Testing

• pnpm lint && pnpm typecheck && pnpm test (1194 passed), pnpm test:matrix (408 tested, 0 missing), pnpm docs:check, and pnpm generate gives no diff.
• New tests:
  • Every old name fails and nothing reaches the scripted MAX.
  • store fetch continues run after run to the chat's start.
  • Both --since and --last, or a pause with no unit, are refused.
  • chats update with a title and a setting sends two requests, and with no change it is refused.
  • account sessions end without --others is refused.
  • chats show --offline gives settings: null.
  • The notice names max upgrade.
• Not run against the real MAX. Before the release: the live scenarios P3, P5 (store fetch --estimate, then --last 20 on one small test chat), P8, G2, T5 and X1 with the new names.

Leave this open for the owner's review.

🤖 Generated with Claude Code