Eight container commands refuse HELP, three of them by telling the client to run HELP

[TinDang97]

The gap

Redis gives every container command a HELP subcommand. Moon serves it on five
containers and refuses it on eight, each with a different error — including two
that report an arity problem, which reads to a client as "the subcommand
exists but you called it wrong".

Measured (moon @ c5395188, --shards 1, vs redis-server 8.6.1)

container	moon <C> HELP	redis
CLIENT	-ERR unknown subcommand 'HELP'	help array
COMMAND	-ERR Unknown subcommand 'HELP'. Try COMMAND HELP.	help array
CONFIG	-ERR unknown subcommand 'HELP'. Try CONFIG HELP.	help array
FUNCTION	-ERR unknown subcommand 'HELP'. Try FUNCTION HELP.	help array
PUBSUB	-ERR unknown subcommand or wrong number of arguments for 'pubsub' command	help array
SCRIPT	-ERR unknown subcommand 'HELP' for 'script' command	help array
XGROUP	-ERR 'XGROUP' command 'UNKNOWN' not recognized	help array
XINFO	-ERR wrong number of arguments for 'xinfo' command	help array

Already correct: ACL, MEMORY, MODULE, OBJECT, SLOWLOG.

Three of these are self-contradicting: CONFIG HELP, COMMAND HELP and
FUNCTION HELP refuse the request with a message that tells the client to run
the exact command it just refused.

Why it matters

HELP is how redis-cli and several driver test suites discover a container's
surface. It is also the fallback a user reaches for after a typo — which is
precisely the moment Moon's own error text points them at it.

Scope

Purely additive: a static help array per container, in the same shape the five
working containers already use. HELP is arity 2 and carries loading +
stale in COMMAND INFO, so the eight new names also belong in
SUBCOMMAND_META once they dispatch — the table's contract is that a published
name must dispatch, and tests/command_list_subcommands.rs::cl3 enforces it.

Note XINFO HELP and XGROUP HELP need care: both currently answer an ARITY
error for an unknown subcommand, so a probe that reads "arity error" as
"exists" will mis-measure them. Send a bogus subcommand WITH arguments as the
control.

Found

Sweeping all 14 containers × valid and bogus subcommands, top-level and inside
MULTI, against a live redis-server 8.6.1 while implementing moon#670.

[TinDang97]

Measured shape of the oracle (redis-server 8.6.1, this host)

Swept all 13 containers' HELP and recorded the RESP element types, not just
"an array came back". Every Redis help reply is uniform:

• *<n> whose elements are all + simple strings — never bulk strings.
• First line is always <CONTAINER> <subcommand> [<arg> [value] [opt] ...]. Subcommands are:
• Last two lines are always HELP and Print this help.

That uniformity is worth building on: a shared constructor that takes the
container name plus its body lines and emits the header and the HELP footer
itself makes a divergent container unrepresentable, rather than merely untested.

This widens the issue: the five "already correct" containers are only correct by type-blind measurement

The original table judged ACL/MEMORY/MODULE/OBJECT/SLOWLOG correct
because a help array came back. Reading the element types instead:

container	elements	leading Subcommands are: line
ACL	+ ✓	present ✓
MODULE	+ ✓	present ✓
OBJECT	bulk ✗	absent ✗
MEMORY	bulk ✗	absent ✗
SLOWLOG	bulk ✗	absent ✗
DEBUG	bulk ✗	absent ✗ (no oracle — Redis refuses DEBUG outright unless enable-debug-command is set, so this one is moon's own convention and only needs internal consistency)

So the fix is 8 new HELPs plus normalising 4 existing ones through the same
constructor. A type-only wire sweep flags bulk-vs-simple inside the array; that
is exactly the instrument class that found this.

Content rule

The help body should advertise what moon dispatches, not what Redis
dispatches — FUNCTION DUMP/RESTORE/STATS are recognised but unimplemented
here, and CLIENT has no CACHING/GETREDIR/REPLY/SETINFO/TRACKINGINFO.
Enforce that with a test asserting every SUBCOMMAND_META name for a container
appears in that container's help text, so the two tables cannot drift.

Interaction with moon#670 (#699)

Once HELP dispatches on all 13, it also stops aborting a transaction: the
queue-time gate in queue_time_rejection reads is_known_subcommand, so adding
the SUBCOMMAND_META entry is what makes MULTI → <C> HELP → EXEC run
instead of EXECABORT. That consequence of #699 disappears with this fix, which
is why this is the next item after it.

Oracle capture kept at tmp/698-redis-help-oracle.txt (not committed).

[TinDang97]

A dead second MEMORY HELP, found while scoping the wiring

src/command/key_extra.rs:111 defines pub fn memory_help(). It has zero
callers — not in src/, tests/, or benches/. Both live call sites
(server_admin.rs:430 and :441) resolve to the module-private
server_admin.rs:840 fn memory_help(), which shadows it within that module.

The two bodies disagree: the dead one uses a MEMORY DOCTOR - Return memory problems reports. dash style and omits MEMORY STATS entirely; the live one
uses the two-line LABEL / description style and lists STATS.

It survives every sweep only because it is pub, which silences dead_code.
That is the inverse of the usual trap — not a private helper hiding from a
handler sweep, but a public one hiding from the compiler. Deleting it is part
of this fix; leaving it means the next person normalising MEMORY HELP has a
50% chance of editing the copy nobody runs and measuring no change.