Coder.Cli can't read a YAML file or pick a target language: it only prints a hard-coded demo, although plan Task 6.1 is checked off #116

What's wrong

Task 6.1 in the implementation plan is ticked as done, but the CLI described there doesn't exist.

Plan: docs/implementation-plan.md L97–101

• Task 6.1: Command-line interface
  • Implement CLI project structure
  • Create commands for YAML processing
  • Add language generation commands
  • Write integration tests for CLI

What exists today

• Coder.Cli/SampleCLI.cs (CoderCLI.Main) accepts only --help and --extended. With any other input, it builds a hard-coded calculate_sum AST and prints its YAML and Python.
• ExtendedDemo.cs is reached through --extended.
• ExpressionDemo.Run() isn't called from anywhere.
• The help text says the languages are "Python, C#". Seven generators are registered.
• No test references Coder.Cli. The csproj sets <SonarQubeExclude> because the project "has no tests of its own".

Why it matters

The plan's "Current Status" section and the checkbox both say the library has a working command-line entry point, but it doesn't. A user who has a .yaml AST can't turn it into source code without writing C# against the library.

Acceptance criteria

• A generate command, e.g. coder generate <file.yaml> --language <id> [--out <path>]. It resolves the generator from AddCoder() / IEnumerable<ILanguageGenerator> by LanguageId, as design.md L189–191 describes. An unknown language id lists the valid ones and exits non-zero.
• A YAML processing command, e.g. validate (deserialize and report errors) or a round-trip/format command.
• The command logic can be called from tests, and integration tests cover success, a missing file, invalid YAML and an unknown language.
• ExpressionDemo is either wired into a demo command or removed, and the help text lists the real languages.
• Once tests exist, reconsider SonarQubeExclude.

Dependencies

None. The plan's Task 7.3 ("documented workflows") would build on this CLI.