docs: give every hierarchical command a subcommand table in the CLI reference

[AvilaJulio]

The command table lists one row per top-level command, with each command's
subcommands packed into its Description cell — where they were listed at all.
A reader scanning the Command column for a command they had not seen
before cannot find enable-branch in it. That is exactly what happened to a
Cube SE helping a customer set up branch-per-PR CI: the command has been in
the data-model cell since #11433 and the page has been live since #11333,
but neither was reachable by scanning.

Expanding the rows in place would flatten each command into several apparent
top-level commands and lose the hierarchy the table exists to show. So this
keeps the table as a flat index and adds subcommand tables below it, grouped
by domain — authentication, deployment, GitHub, data model, dbt, workspace
content, users and access control, administration, embedding, agents/app.
Each hierarchical row links to its group, and the narrative sections
(Data model Git workflow, dbt sync) link into the same tables rather than
repeating them.

Every subcommand comes from cube <command> --help on CLI 1.7.33, checked
programmatically against all 23 hierarchical commands, so the tables match
what the binary reports. That surfaced a fair amount the page did not mention
at all — the third-level trees (notifications recipients,
integrations tokens, embed tenant, attributes values,
scim users/groups), plus exit-dev-mode and file-hashes, both used by
the Git workflow section but missing or unexplained.

The enable-branch paragraph gets its own ### heading so the tables have an
anchor to link to, and so it earns a TOC entry.

Verified against a local mintlify dev render: all 14 cross-references
resolve to real heading ids, no link reference renders literally, and the
top-level table is unchanged in shape.

🤖 Generated with Claude Code