Fix changelog bundle --no-resolve

[lcawl]

Summary

While testing #2773 I discovered that the bundle.resolve in the changelog configuration file was overruling the docs-builder changelog bundle command option --no-resolve.
This PR fixes that behaviour so that the command options have precedence over the config options.

Steps to test

I tested this PR against files in elastic/kibana#250840

1. Verify that the changelog configuration file has bundle.resolve setting. For example:

   bundle:
   # Whether to resolve (copy contents) by default
   resolve: true

2. Create a bundle with the --no-resolve option. For example:

   docs-builder changelog bundle \                                                                                                  
   --config ~/Documents/GitHub/kibana/docs/changelog.yml \
   --input-products "kibana 9.3.0 *" \
   --directory ~/Documents/GitHub/kibana/docs/changelog \
   --output ~/Documents/GitHub/kibana/docs/releases/kibana/9.10.0.yaml \
   --repo kibana --owner elastic \
   --output-products "kibana 9.10.0 *" \
   --no-resolve

Before this PR, the command-line option was ignored and the bundle was created with resolved details, for example:

products:
- product: kibana
  target: 9.10.0
  repo: kibana
entries:
- file:
    name: 238646.yaml
    checksum: 43bf0846eeb1363b4c697cbdaf2438344d327b56
  type: feature
  title: Edit feature condition and add feature discover url
  products:
  - product: kibana
    target: 9.3.0
  areas:
  - Management
  pr: "238646"
  issues:
  - https://github.com/elastic/kibana/issues/238178

With this PR fix, the command line option is heeded. For example:

products:
- product: kibana
  target: 9.10.0
  repo: kibana
hide-features:
- test_feature1
entries:
- file:
    name: 238646.yaml
    checksum: 43bf0846eeb1363b4c697cbdaf2438344d327b56
- file:
    name: 244072.yaml
    checksum: 186d612d19a18c671913dc0d1dabe558f5e1f3ad

Implemention details

src/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cs

• BundleChangelogsArguments.Resolve: bool → bool? so null (unspecified), true (--resolve), and false (--no-resolve) are all distinguishable.
• ApplyConfigDefaults: input.Resolve || config.Bundle.Resolve → input.Resolve ?? config.Bundle.Resolve — uses ?? so an explicit false from the CLI is never overridden by the config.
• BuildBundle call site: input.Resolve → input.Resolve ?? false — safe fallback when no config and no CLI flag.

src/tooling/docs-builder/Commands/ChangelogCommand.cs

• Resolve = shouldResolve ?? false → Resolve = shouldResolve — preserves null (unspecified) so ApplyConfigDefaults can apply the config value when the user doesn't pass either --resolve or --no-resolve.

tests/Elastic.Changelog.Tests/Changelogs/BundleChangelogsTests.cs

• Added BundleChangelogs_WithExplicitResolveFalse_OverridesConfigResolveTrue: sets resolve: true in config, passes Resolve = false to the service, and asserts the bundle contains only a file reference (not inlined content).

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

2. If you answered "Yes" to the previous question, please specify the tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).

Tool(s) and model(s) used: composer-1.5, claude-4.6-sonnet-medium

[Mpdreamz]

I am not sure about this one.

If command line conflicts with config we should make this an error.

In my head someone will only call this manually with commandline flags on rare occasions. They should not be able to create bundles that conflict with the config IMO

[lcawl]

In my head someone will only call this manually with commandline flags on rare occasions. They should not be able to create bundles that conflict with the config IMO

I agree that the command-line invocations will hopefully become rare and for the automated scenarios we want teams to set their options in the configuration file for consistency.

I think there's still a use case for creating one-off bundles, however (even if just for testing purposes as I was doing). I don't think it's good practice to require them to update the (shared) configuration file just to accomplish their exceptional goals.

[Mpdreamz]

I see your point @lcawl 👍