The pending_command flag is documented as indicating a client has a fully parsed command ready for execution. However, it was only set in the IO thread path, not in the main thread processInputBuffer path which parses and executes directly without ever setting the flag. This inconsistency meant blocking APIs like blockClientInUseOnKeys had to require callers to manually set pending_command = 1 before calling.

This change:

• Sets pending_command = 1 in processInputBuffer when the command is fully parsed.
• Clears it in commandProcessed after execution completes.
• Removes redundant clears in processPendingCommandAndInputBuffer and unblockClientOnKey.

Now any command that blocks during processCommand naturally has pending_command = 1 already set, without caller intervention.

Exception:

• WAIT and WAITAOF explicitly clear pending_command before blocking, since processClientsWaitingReplicas uses it to distinguish reply commands (pending_command = 0) from re-execution commands like CLUSTER SETSLOT (pending_command = 1).
• Module clients clear pending_command in moduleHandleBlockedClients before unblocking, since their reply is already handled by the module's callback (reply callback for VM_BlockClient, key-notification callback for VM_BlockClientOnKeys). The exception is module auth-in-progress clients, which keep pending_command = 1 because they need re-execution after authentication completes.