fix(cli): derive --help tool list from the MCP registry

[DeusData]

Problem

codebase-memory-mcp --help listed 14 tools and omitted check_index_coverage — the headline feature of v0.9.1. MCP tools/list correctly returned all 15, and the tool itself worked (cli check_index_coverage and its --help were fine); only the top-level help was wrong.

Root cause: the Tools: block in print_help() was a hand-maintained copy of the tool registry. When check_index_coverage was added to TOOLS[] in src/mcp/mcp.c, nothing forced the help string to follow, so it drifted silently.

Fix

Derive the help line from the registry instead of testing a second copy — a list that cannot drift beats a test that catches drift:

• cbm_mcp_tools_help_list() renders the Tools: block directly from the same TOOLS[] array that answers tools/list, wrapped for 80-column terminals in the existing style (registry order preserved).
• print_help() now prints that render; the hard-coded list is gone.
• cbm_mcp_tool_count() / cbm_mcp_tool_name() expose the registry, following the existing cbm_mcp_tool_input_schema() precedent.
• New test mcp_tools_help_list_matches_registry pins the render against the registry: every advertised tool appears, comma cardinality equals registry count (catches truncation/duplication from a formatter bug), and lines stay under 80 columns. A future 16th tool is covered automatically — no test update needed.

Verification

• ./build/c/codebase-memory-mcp --help | grep -c check_index_coverage → 1 (was 0); the help block now lists all 15 registry tools in registry order.
• mcp suite green (180 passed); bind proven by temporarily re-introducing the omission in the formatter → test fails with strstr(help, name) is NULL, restored → green.
• make -f Makefile.cbm lint-ci clean.

Fixes #1361

[DeusData]

CodeQL found two high-severity alerts in the first commit, and it was right — pushed 644c8fd to fix them.

The help-list builder accumulated snprintf's return value, which is the length it would have written rather than what it did. Once len passes cap, the next cap - len underflows to a huge size_t and the following write lands outside the buffer.

Worth noting what makes this uncomfortable: it is the same class as #1173, which merged an hour before this — there blen walked past a 2 KB buffer by exactly the same mechanism.

The capacity computed here happens to be sufficient for the current registry, so nothing actually overflowed. That makes it the more dangerous shape rather than the safer one: correctness depended on an argument made ten lines away in the cap loop, so renaming a tool or changing the wrap column would have converted it into an out-of-bounds write with nothing in the function to notice. help_append() now returns the bytes actually written, clamped to the remaining space, so len <= cap - 1 is a local invariant that survives whatever the registry becomes.

Verified before pushing: builds clean under -Werror, --help still renders all 15 tools in registry order with identical wrapping, mcp + cli suites 437 passed / 0 failed, and lint-ci clean.