Replace Spectre.Console.Cli with bv's own CLI layer

[rdeago]

Closes #278.

Removes the Spectre.Console.Cli dependency and replaces it with bv's own command-line parsing, dispatch, and help rendering. Spectre.Console proper (markup, AnsiConsole, the logger) stays as the console backbone.

What's in here (commit by commit)

1. Namespace unclutter — split the overloaded Cli namespace into Commands, CommandLine, and Infrastructure.Execution.
2. Parser primitives + first test project — CliArgSplitter, CliOptionReader, BvOptionAttribute, ParsedCommandLine, plus tests/Buildvana.Tool.Tests (TUnit on Microsoft.Testing.Platform — the repo's first test project).
3. The flip — own dispatcher (CommandRegistry + IBvCommand), GlobalSettings (merging the old globals + base settings), BvHelpRenderer, the -- forwarding rule, Console.CancelKeyPress wiring; deletes the Spectre adapters and drops the Spectre.Console.Cli package.
4. Internalize the tool's types now that Spectre no longer forces them public.
5. Rename Commands → Subcommands (it shadowed LibGit2Sharp.Commands).
6. Changelog — update the forwarding / -c bullets for the -- separator.

Behavior change

The only intentional user-facing change is -- forwarding: bv build/restore/test/pack forward only what follows -- (e.g. bv build -- -p:Foo=Bar); option-looking tokens before -- now error and point at the separator. bv release rejects --. The rest of the option surface is behavior-preserving.

Test plan

• dotnet bv pack — clean (Release build + tests + artifacts).
• 47 unit tests pass (parser, reader, splitter, ReleaseSettings, argument validation, command lookup, help reflection).
• ReSharper inspectcode --severity=WARNING — 0 results.
• Manual against the built bv: root/per-command help, --version, and the --/unknown-option/unknown-command error paths (correct messages + exit codes).

[rdeago]

@claude please review this PR.

[claude]

Claude finished @rdeago's task in 5m 39s —— View job

---

PR Review

• Gather context and understand the request
• Read key changed files
• Analyze correctness, style, and design
• Post review findings

---

Overall this is a clean, well-structured migration. The layering is clear (CliArgSplitter → CliOptionReader → ParsedCommandLine → CommandArgumentValidator → dispatch), the test coverage is solid (47 tests across all new units), and ReSharper came back clean. I have three minor observations.

---

1. Stale "Spectre commands" in BuildSteps.cs XML doc

src/Buildvana.Tool/Subcommands/BuildSteps.cs, line 24:

/// Bodies of the individual pipeline steps (clean / restore / build / test / pack), independent of the
/// Spectre commands that invoke them.

Spectre commands is a leftover from before the migration. It should be bv subcommands (or similar).

Fix this →

---

2. CommandParameters — class vs record

src/Buildvana.Tool/CommandLine/CommandParameters.cs:

ParsedCommandLine and GlobalSettings are both records. CommandParameters is a class with init-only properties. There's no strong reason for the asymmetry — it serves the same role as a lightweight data carrier passed through DI. A sealed record with two properties would be consistent with its neighbours:

internal sealed record CommandParameters(
    IReadOnlyList<string> Options,
    IReadOnlyList<string> Forwarded);

This is purely a style observation; the class form works correctly.

---

3. Implicit Spectre markup in Description attributes

src/Buildvana.Tool/Infrastructure/Execution/BvHelpRenderer.cs, line 143 and src/Buildvana.Tool/Subcommands/ReleaseSettings.cs, --bump property:

WriteOptionGrid passes description directly to new Markup(...) without escaping:

grid.AddRow(new Markup(Markup.Escape(names)), new Markup(StripTrailingPeriod(description)));
//                                            ^^^^^^ description is NOT escaped

This is intentional — ReleaseSettings's --bump description uses [bold]none[/] etc. — but the contract is invisible at the point of decoration. A maintainer adding a new option with [value] in the description text (meaning a placeholder, not markup) would get a Spectre markup parse error or silent swallowing of the content.

Worth adding a brief note in BvOptionAttribute's or BvHelpRenderer's doc comment that descriptions are rendered as Spectre markup, not plain text. Alternatively, a comment on Description usage in the existing settings classes would do the same job.

---

Everything else looks good

• CliArgSplitter: the two-pass design (separator split → global strip → classify) is simple and easy to follow. The "last wins" semantic for repeated options matches the existing global behavior and is tested.
• CliOptionReader: the mutating-list approach is clear and the Remaining contract (for catching unknown options) is well-exercised in ReleaseSettings.Parse.
• CommandArgumentValidator: the forwarding / non-forwarding split is correct. The error message pointing users at -- <arg> is helpful.
• BvHelpRenderer: the usage of MarkupInterpolated for user-supplied content (command names, option names) correctly auto-escapes them, while the decoration ([grey]...[/]) in the forwarding note is genuine markup. No markup-injection risk.
• CommandRegistry.Discover(): the pipeline-name guard that fails fast on a typo in PipelineCommandNames is a nice safety net.
• Test project: using Microsoft.Testing.Platform with TUnit on the first test project in the repo is consistent with the changelog entry about MTP being the only supported runner.
• Program.Main flow: the --version → logo → null-subcommand → help → validate → execute order is correct. The --color / --no-color XOR logic correctly leaves the console profile untouched when both or neither are set.