fix: attach reindex-fts and repair-summaries to the memory-pro command group

[gorkem2020]

Every user-facing command in this file is meant to live under the memory-pro group (program.command("memory-pro"), built at the top of registerMemoryCLI) so it can be invoked as memory-pro <command>. reindex-fts and repair-summaries were instead registered directly on the root commander program. Since the host's dispatcher only routes the one declared root command (memory-pro), both commands were unreachable through any actual invocation path, no matter how they were called. This looks like it has been the case since whichever commit introduced them; there was no test exercising the actual command tree that would have caught it.

• reindex-fts and repair-summaries are now attached to the memory group variable instead of program, so they're invoked as memory-pro reindex-fts and memory-pro repair-summaries, matching every other command in this file.
• Added a structural test that instantiates createMemoryCLI against a minimal stub context on a fresh commander Command and inspects the actual registered command tree: the root program must expose exactly one command (memory-pro), and both reindex-fts and repair-summaries must be reachable underneath it.

Test plan

• Red-first: test/cli-subcommand-attachment.test.mjs, three tests, all failed before the fix (root program had four commands instead of one; neither reindex-fts nor repair-summaries appeared in the group's subcommand list) and passed after.
• Grepped the test suite and docs for any existing reference to invoking these two commands; found none, so nothing else assumed the old (broken) root-level path.
• npm run build (tsc) clean.
• Full local npm test chain green (one test skipped: a known host-side port 11434 conflict unrelated to this change).
• test/cli-subcommand-attachment.test.mjs registered in both package.json's test script and scripts/ci-test-manifest.mjs; manifest verification passes.

Notes for reviewers

No user-facing invocation path changes for anyone currently on master, since neither command was reachable before this fix either way. This just makes two already-shipped features usable for the first time.

[app3apps]

Reviewed head 3bb1522. The command-tree attachment itself is correct, the three focused tests pass, the build is clean, and GitHub CI is green. The generated dist/index.js catch-up is reproducible from the already-merged source change and is not a blocker.

However, this PR's stated effect is to make these maintenance actions usable through the supported CLI path for the first time, and both action bodies have unsafe observable behavior:

1. cli.ts:2162-2198 treats a mismatch between the first 60 characters of text and l0_abstract as staleness. L0 is designed to be a concise generated abstract, so valid enriched memories are classified as stale; because --dry-run defaults to false, their L0/L1/L2 metadata is overwritten with raw text. Conversely, a real text change after character 60 is missed. Please use reliable source-text provenance/versioning (with a conservative legacy policy), make mutation explicitly opt-in, and add action-level regressions for both cases.

2. src/store.ts:2630-2642 suppresses dropIndex failures. The surviving index then makes recreation a no-op, but the method still marks FTS available and returns success. Please propagate/verify failed drops and verify that a replacement index exists before reporting success, with a failed-drop regression test.

These need to be safe before the PR exposes the commands as supported maintenance operations.