feat: Add platform-specific package manager contexts (Brew, Chocolatey, Winget)

[thomhurst]

Summary

Adds package manager abstractions to the core ModularPipelines package for macOS and Windows, following the existing IAptGet pattern for Linux:

• IBrew: Homebrew operations for macOS (install, uninstall, update, upgrade, list, search, info, tap, untap, cleanup)
• IChocolatey: Chocolatey operations for Windows (install, uninstall, upgrade, list, search, info, outdated, pin)
• IWinget: Windows Package Manager operations (install, uninstall, upgrade, list, search, show, export, import, source)

Each interface includes strongly-typed options classes with common CLI flags and command-specific parameters, registered in DI as scoped services.

Files Changed: 37 files (3,089 insertions)

Closes #1995

Test plan

• Build succeeds with 0 errors
• Follows existing IAptGet pattern
• All options classes have proper CLI attributes
• Services registered in DI

🤖 Generated with Claude Code

[thomhurst]

Summary

This PR adds platform-specific package manager abstractions (Brew, Chocolatey, Winget) to the core ModularPipelines package, following the existing IAptGet pattern.

Critical Issues

BLOCKING: Architectural inconsistency and code duplication

1. Chocolatey and WinGet already exist as separate packages with auto-generated code:

   • src/ModularPipelines.Chocolatey package exists with IChoco interface (auto-generated)
   • src/ModularPipelines.WinGet package exists with IWinget interface (auto-generated)
   • This PR creates duplicate IChocolatey and IWinget interfaces in the core package with manually written code

2. Violates the documented architecture (from CLAUDE.md:68-79):

   • "Each tool (DotNet, Git, Docker, etc.) has its own package"
   • "Tool options classes (e.g., GitAddOptions, DotNetBuildOptions, DockerRunOptions) are auto-generated"
   • "Do not modify generated options classes directly"

3. This creates confusion:

   • Users will have TWO different ways to access Chocolatey: IChoco (existing, auto-generated, in separate package) vs IChocolatey (new, manual, in core package)
   • Same for WinGet: existing IWinget (auto-generated) vs new IWinget (manual, different namespace)
   • The existing packages are comprehensive and auto-generated from CLI specs - the manual versions will be incomplete and harder to maintain

Recommended approach:

• Option A (Recommended): For consistency with existing tool packages, create a ModularPipelines.Brew package with auto-generated code using the OptionsGenerator
• Option B: If the goal is to have lightweight wrappers in core (like AptGet), then:
  • Remove Chocolatey and WinGet from this PR (they already exist as proper packages)
  • Keep only Brew (which doesn't have a separate package yet)
  • Update documentation to clarify when tools go in core vs separate packages

Files showing existing packages:

• src/ModularPipelines.Chocolatey/Services/IChoco.cs:15
• src/ModularPipelines.WinGet/Services/IWinget.cs:15

Verdict

⚠️ REQUEST CHANGES - Critical architectural duplication must be resolved

[thomhurst]

Closing - package managers should be in separate projects (like existing ModularPipelines.Chocolatey and ModularPipelines.WinGet). Will create ModularPipelines.Homebrew as a new project instead.