Purpose

Provides a repo fixture to reproduce the problem described in #1252 (based on this comment)

Rationale

Added a new repo following the examples in other fixtures.
Had to made one more addition: simulate_change_commits_n_rtn_changelog_entry() fixture always worked with the file_in_repo. For this specific flow it caused merge conflicts, because commit in the feature branch was made before default branch was merged into a feature branch. Made this parameter configurable.

How did you test?

I ran the test and it failed with the expected error (empty ## v0.3.0 (2025-05-31) changelog entry)

>           assert expected_md_changelog_content == actual_md_changelog_content
E           assert == failed. [pytest-clarity diff shown]
E             
E             LHS vs RHS shown below
E             
E               # CHANGELOG
E               
E               <!-- version list -->
E               
E               ## v0.3.0 (2025-05-31)
E             + 
E             + ### Features
E             + 
E             + - Add new feature in the feature branch
E             +   
E             ([`0000000`](https://example.com/example_owner/example_repo/commit/0000000000000
E             000000000000000000000000000))
E               
E               
E               ## v0.2.0 (2025-05-31)
E               
E               ### Features
E               
E               - Add another feature
E                 ([`0000000`](https://example.com/example_owner/example_repo/commit/000000000
E             0000000000000000000000000000000))
E               
E               
E               ## v0.1.0 (2025-05-31)
E               
E               - Initial Release
E             

How to Verify

1. Comment (or remove @pytest.mark.xfail decorator on the tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_w_feature_branch_and_release_in_default.py test.
2. run pytest -vv --comprehensive tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_w_feature_branch_and_release_in_default.py

PR Completion Checklist

• Reviewed & followed the Contributor Guidelines

• Changes Implemented & Validation pipeline succeeds

• Commits follow the Conventional Commits standard
  and are separated into the proper commit type and scope (recommended order: test, build, feat/fix, docs)

• Appropriate Unit tests added/updated

• Appropriate End-to-End tests added/updated

• Appropriate Documentation added/updated and syntax validated for sphinx build (see Contributor Guidelines)