[bv] English help output and kebab-case-only release options

[rdeago]

Summary

Closes #258 (Phase 1 of #257). Three coordinated cleanups to the bv CLI option surface:

• English help/diagnostics on every host. Set CultureInfo.DefaultThreadCurrentUICulture = CultureInfo.InvariantCulture at the entry point of Main so Spectre.Console.Cli's resource lookup lands on the English (invariant) Resources.resx regardless of system locale.

• Drop camelCase option aliases. Multi-word options accepted both forms (e.g. --mainBranch|--main-branch); only kebab-case is accepted now.

• Simplify long bv release option names. Five renamings:

  • --versionSpecChange → --bump
    The --bump description is multi-line and uses Spectre markup to spell out each accepted enum value, since the renamed option no longer carries a self-explanatory name.
  • --checkPublicApiFiles → --check-public-api
  • --updateChangelogOnPrerelease → --unstable-changelog
  • --ensureChangelogNotEmpty → --require-changelog
  • --updateSelfReferences → --dogfood

  Property names, OptionsService keys, and derived env-var names follow.

Notes for follow-up

• .github/workflows/release.yml still sets VERSION_SPEC_CHANGE etc. and isn't updated in this PR: the workflow runs against the published bv (currently 2.0.103-preview, which speaks the old options), so the rename must land with the dogfood commit that pins the new bv version. A separate issue will track this, along with three latent wiring bugs in the same workflow that this PR surfaced (FORCE_UPDATE_CHANGELOG / CHECK_CHANGELOG / CHECK_PUBLIC_API inputs that were silently ignored against the old option keys).
• The env-var-as-option fallback in OptionsService deserves its own retire/replace decision; will be filed as an enhancement issue.

Test plan

• dotnet bv pack — succeeds, NuGets produced.
• dotnet dnx JetBrains.ReSharper.GlobalTools inspectcode --severity=WARNING … — zero results.
• Manually verify on a non-English host that bv build --help shows DESCRIPTION: / USAGE:.
• Spot-check bv release --help to confirm the multi-line --bump description renders correctly.

🤖 Generated with Claude Code

[rdeago]

@claude please review this PR.

[claude]

Claude finished @rdeago's task in 3m 30s —— View job

---

PR Review

• Read changed files
• Analyze diff
• Review correctness, style, and architecture
• Post findings

---

Overall the implementation is clean and consistent. The three coordinated changes (invariant culture, dropped camelCase aliases, renamed release options) are wired correctly end-to-end: ReleaseSettings.cs → SettingsApplier.cs → ReleaseCommand.cs GetOption keys all match, and the env-var derivation from the new camelCase keys (checkPublicApi → CHECK_PUBLIC_API, unstableChangelog → UNSTABLE_CHANGELOG, etc.) is correct per OptionsService's regex chain.

Two issues to flag:

---

Issue 1 — CHANGELOG example names an option that no longer exists (medium priority)

CHANGELOG.md line 24:

Use the kebab-case form (e.g. --main-branch instead of --mainBranch, --version-spec-change instead of --versionSpecChange).

--version-spec-change was never the landing name; it was an intermediate alias that got swept away by the rename to --bump in the same PR. A user reading only the first BREAKING CHANGE bullet would try --version-spec-change, get an "unknown option" error, and have to dig further. The safe fix is to replace that half of the example with one that survives the rename, e.g. --main-branch → --mainBranch appears twice, or pick any of the three unambiguous renames (--check-public-api, --unstable-changelog, --require-changelog).

Fix this →

---

Issue 2 — "Known problems" phrasing uses -- prefix in a non-CLI context (low priority)

CHANGELOG.md line 33:

…or set --unstable-changelog to true so prerelease runs always have a non-empty release commit.

The original text said updateChangelogOnPrerelease (the raw option key, no --). Replacing it with --unstable-changelog makes it look like CLI syntax, but "set --unstable-changelog to true" is an odd construction — you'd either pass --unstable-changelog true on the CLI or export UNSTABLE_CHANGELOG=true in the workflow. The -- prefix combined with "set … to true" is slightly confusing about which surface the user is touching.

Suggested phrasing: "…or set the UNSTABLE_CHANGELOG environment variable to true …" (matches the actual mechanism), or "…or pass --unstable-changelog true to dotnet bv release …" (matches CLI usage).

---

Everything else looks good

• Program.cs: Setting DefaultThreadCurrentUICulture = InvariantCulture at the very top of Main, before any framework code runs, is the correct placement. The comment accurately explains the mechanism (Spectre's resource lookup falls through to Resources.resx, which is the English invariant fallback).
• ReleaseSettings.cs: The raw string literal for --bump is well-formed; the closing """ at 8-space indentation strips correctly, leaving Version-spec change to apply:\n - [bold]none[/]…. Spectre markup in Description attributes renders in help output — no concerns there.
• SettingsApplier.cs: The mainBranch camelCase key at line 37 is intentionally untouched (only the CLI alias was dropped, not the internal option key), and maps to MAIN_BRANCH as before.
• The acknowledged workflow-file follow-up (VERSION_SPEC_CHANGE etc.) and the OptionsService env-var retire/replace issue are appropriate deferrals for separate tracking.

[rdeago]

Issue 1 — CHANGELOG example names an option that no longer exists (medium priority)

Fixed by removing affected entry from changelog as no longer relevant after this PR.

Issue 2 — "Known problems" phrasing uses -- prefix in a non-CLI context (low priority)

Wording improved on whole affected changelog entry.