fix(command): treat subcommands of hidden commands as hidden recursively

[AdamMagued]

Fixes #2372

Summary

• Propagated hidden visibility to subcommands when parent command has Hidden: true.
• Added unit tests covering hidden command recursion in help output.

Verified via container sandbox test suite.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] Changes how command visibility inheritance works in the CLI framework.

The PR appears safe to merge, with a non-blocking loss of shell choices when the completion command is made public.

Findings

1.  Public completion loses shell choices ▶

Summary

The PR makes subcommands inherit hidden visibility in help, categories, shell suggestions, and Walk.

• Adds tests for nested hidden commands and generated completion commands.
• Explicitly hiding completion shells also removes their choices when users make the completion command public.

_{Reviews (1) · Last reviewed commit: "fix(command): inherit Hidden visibility ..." · Reviewed by Greptile}

[greptile-apps]

Public completion loses shell choices

Setting cmd.Hidden = false in ConfigureShellCompletionCommand no longer makes the completion shells visible. Each shell now has its own Hidden: true, so help and shell suggestions omit bash, zsh, fish, and pwsh even when their parent is public. Users can still run them by typing the full command.

Leave the shells visible by default and let isHidden() inherit their parent's visibility. Add a test for the documented customization.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[AdamMagued]

Removed explicit Hidden: true on individual shell completion subcommands so their visibility dynamically inherits from the parent completion command via isHidden(). Added unit tests covering shell subcommand visibility in help output, shell suggestions, and dynamic customization when the completion command is made public.