[Automated] Update pulumi CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to pulumi CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[claude]

Automated PR Review - Pulumi CLI Options Update

This PR is generated by the ModularPipelines.OptionsGenerator and adds the --otel-traces flag (OpenTelemetry traces export endpoint) across 100 Pulumi command options classes. The change is consistent and mechanically correct. A few architectural observations worth noting:

---

Primary Concern: Global Flag Duplication Instead of Inheritance

The most significant pattern to call out is that --otel-traces is being added individually to every single one of ~100 command-specific options classes, rather than to the PulumiOptions base class.

Looking at PulumiOptions.Generated.cs, the base class is currently empty:

[CliTool("pulumi")]
public abstract record PulumiOptions : CommandLineToolOptions
{
}

Yet flags like --non-interactive, --profiling, --tracing, and now --otel-traces appear identically in every subcommand options class. These are Pulumi global flags (they appear in pulumi --help's Flags: / Global Flags: section and are inherited by all subcommands).

Why this matters architecturally:

• When Pulumi adds or modifies another global flag in a future release, the generator will again produce a diff touching 100+ files
• Consumers setting OtelTraces on a PulumiUpOptions instance cannot do so via the PulumiOptions base type, reducing polymorphic usability
• The generated code is harder to inspect — it's not clear which options are "global" vs command-specific without reading each file

Better approach: The generator's PulumiOptions (or the CobraCliScraper base class) should detect global flags at the root command level and emit them once on the base class, suppressing them from subcommand classes via deduplication during generation. The ParseOptions method in CobraCliScraper.cs already has a seenOptions deduplication set within a single command — the same logic could be extended cross-command for global flags identified from the root --help output.

---

Minor: OtelTraces Type Could Be More Descriptive

The property is typed as string?:

[CliOption("--otel-traces", Format = OptionFormat.EqualsSeparated)]
public string? OtelTraces { get; set; }

The description says it accepts file:// paths or grpc:// endpoints. While string? is pragmatic and the generator cannot infer a richer type from CLI help text alone, this is a case where a future manual extension (the pattern already supported by the codebase for non-generated overrides) could provide a typed wrapper — e.g., a Uri-validated helper — for better discoverability.

---

What the PR Gets Right

• The change itself is mechanically correct: the [CliOption] attribute, OptionFormat.EqualsSeparated, and the XML doc comment are all consistent with every other option in the generated files
• The AssemblyInfo.Generated.cs timestamp bump correctly signals regeneration
• Auto-merge via squash is the right strategy for automated dependency PRs like this
• The generator's CobraCliScraper approach of parsing --help output directly (rather than scraping web docs) is sound and ensures the generated options stay in sync with whatever version of pulumi is actually installed in CI

---

Summary: The PR is safe to merge as-is. The architectural note above about global flags in the base class is a generator-level improvement opportunity, not a blocker for this PR.