Changelog profile parity - final phases

[lcawl]

Summary

This pull request is a continuation of #2791
It implements the final phases of an effort to get the profile-based docs-builder changelog bundle and docs-builder changelog remove invocations to parity with the command-line-option method.

Design Principles

1. Mutually exclusive invocation: When using a profile (changelog bundle <profile> <arg> or changelog remove <profile> <arg>), any filter- or output-related command options must be rejected with an error. Profile config provides all such values.
2. Allow minimal CLI overrides: Only for remove: --dry-run and --force may be used with profiles. No other CLI options are allowed when using a profile.
3. Path derivation from config: When using a profile, paths are derived from the changelog configuration file (discovered by default, e.g. docs/changelog.yml):
   • Input directory (bundle.directory): The directory containing changelog YAML files for both bundle and remove.
   • Bundles directory (bundle.output_directory): For remove, the directory scanned for bundle dependencies. No --config or --directory override — profile invocations rely on the config file.
4. Core functionality parity: Both invocation styles must support the same core filtering and output behaviors; profiles achieve this via config fields.

---

Implementation details

Phase 3 (profile-based enhancements):

• Accept a newline-delimited URL list file as a profile argument, resolving
  to PR or issue filters based on the URLs found in the file
• Support combined <version> <report|url-list> profile arguments so the
  version can be used for {version} substitution while the report/file
  drives filtering
• Wire Issues filter through ProfileFilterResult into bundling and remove services

Phase 4 (option-based enhancements):

• Add --report option to both changelog bundle and changelog remove,
  accepting a promotion report URL or local HTML file path
• Enforce stricter validation for file-based --prs and --issues inputs:
  every line must be a fully-qualified GitHub URL

Phase 5 (tests and documentation):

• Add 264-test coverage for all new behaviours in BundleChangelogsTests
  and ChangelogRemoveTests
• Update changelog-bundle.md, changelog-remove.md, and contribute/changelog.md
  to document new arguments, options, validation rules, and examples

Bug fixes

Two real code bugs discovered and fixed:

Bug 1 — changelog bundle profile mode: bundle.directory was skipped as output fallback

ProcessProfile computed the output directory as:

bundle.output_directory → input.OutputDirectory (dead field in CLI) → input.Directory (always null in profile mode) → CWD

So when neither bundle.output_directory was set, it jumped straight to CWD, silently ignoring bundle.directory. The docs said it should use bundle.directory as the fallback, but the code didn't. Fixed to:

bundle.output_directory → input.OutputDirectory (API/test override) → bundle.directory → CWD

Bug 2 — changelog remove option mode: bundle.directory was never consulted

ChangelogCommand.Remove eagerly resolved directory ?? CWD before passing it to the service. This meant ApplyConfigDefaults's bundle.directory branch was unreachable — if you had bundle.directory set in your config but didn't pass --directory, remove would always default to CWD. Fixed to pass null when --directory is absent, letting the service's fallback chain work correctly.

The consistent fallback order (now matches across both commands):

Input directory (where changelogs are read from):

Priority	Profile mode	Option mode
1	bundle.directory	--directory
2	CWD	bundle.directory
3	—	CWD

Output directory (bundle only — remove has no output file):

Priority	Profile mode	Option mode
1	bundle.output_directory	--output
2	bundle.directory	bundle.output_directory
3	CWD	--directory → bundle.directory → CWD

Outstanding work

• Some further cleanup of the changelog.md is necessary (for example to add profile-based examples since most of the bundle section of the doc relates to the command-options).
• Test this PR against outstanding PRs to verify

Generative AI disclosure

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

• Yes
• No

3. 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