feat: unify CLI output format flag and make it follow conventions established in other tools

[michael-johnston]

Is your feature request related to a problem? Please describe.

The --output-format flag (and related output flags) are inconsistent and confusing across commands:

• The flag is named differently across commands: --output (ado get), --output-format (ado show entities/requests/results), --format (ado show summary).
• ado show entities has no short form -o, unlike the other show commands — (minor bug)
• The format value for "rich terminal table" is called default in ado get, console in show commands, and table in ado show summary.
• Most frustratingly, passing --output-format csv or --output-format json writes to an auto-generated file in the current directory rather than printing to stdout. This makes piping impossible (ado show results ... -o csv | python analyse.py does not work), creates files without explicit user intent, and conflates two orthogonal concerns — output format and output destination.
  • This behaviour is very complicated to explain to agents via SKILLS who assume existing conventions established by other similar tools (e.g. see below) hold

Describe the solution you'd like

1. Unify the flag name to --output / -o across all commands.
2. Standardize format names: use table consistently for the rich terminal rendering (currently default/console/table). Other formats (json, yaml, csv, md) stay as-is.
3. Send all data to stdout: --output csv should print CSV to stdout, not write a file. Users redirect with the shell as expected:

   ado show results operation <id> -o csv > results.csv
   ado show results operation <id> -o json | jq '.[]'

4. Add an explicit --output-file <path> flag as a separate, optional destination override for users who want a named file without shell redirection. It works with any format and prints ✔ Output saved as <path> to stderr.
5. Strict stdout/stderr discipline: stdout carries all data output; stderr carries only diagnostics (errors, warnings, progress spinners, hints, empty-data notices, and the --output-file confirmation).

Describe alternatives you've considered

• Keep auto file-writing but make the filename configurable (e.g. --output-file). Rejected because it still breaks piping — the fundamental Unix composability issue remains unless data goes to stdout by default.
• Keep separate flag names per command. Rejected because it adds unnecessary cognitive overhead and is inconsistent with tools users already know (kubectl, helm, gh all use --output/-o uniformly).

Additional context

This aligns the CLI with established conventions from comparable tools:

• kubectl: --output/-o everywhere; all data to stdout; users redirect with >; stderr for errors/warnings only.
• helm: --output with table/json/yaml to stdout.
• gh: -F/--format with machine formats to stdout.

Key files involved in the implementation:

• orchestrator/cli/models/types.py — format enums
• orchestrator/cli/commands/show_*.py and get.py — flag definitions
• orchestrator/cli/utils/output/dataframes.py — df_to_output, the central place where file-writing currently happens
• orchestrator/cli/resources/discovery_space/show_summary.py
• website/docs/getting-started/ado.md — documentation

[michael-johnston]

We should do this asap now there is also -o name.

[AlessandroPomponio]

The table output type from ado show summary is a bit deceiving, it outputs a markdown table, while the md option outputs a markdown summary in prose.

We might want to have additional output types there: table (consistent with the rest), md, md-table