Release produced major version instead of expected patch

[Shubham13]

Describe the bug
The release pipeline bumps the version as major when we expect patch. The release is computed from all PRs merged since the last release tag, and if any of those PRs is a breaking change, the version is correctly bumped to major per semver. The confusion is that the build is triggered by a single, patch-level merge, so it looks like that merge caused a major release. There is no clear indication in logs or UI that the major bump was due to an earlier breaking-change PR included in the same release.

To Reproduce

1. Have a released version (e.g. 103.0.0) and tag it.
2. Merge a PR that is a breaking change (e.g. labeled "Breaking Change" or conventional commit with BREAKING CHANGE / feat!:).
3. Merge one or more later PRs that are patch-level (e.g. fix, chore, or "Version: patch").
4. Run the release step (e.g. on the next CI run after the patch-level merge).
5. Observe: the new release is major (e.g. 104.0.0) and the release notes list all merged PRs since the last tag, including the breaking-change PR.

Expected behavior
When the build is triggered by a patch-level merge, we expect the next release to be a patch (e.g. 103.0.0 → 103.0.1), unless the current merge is a breaking change. We expect either: (a) the release to be scoped to the PR that triggered the build, or (b) clear visibility (e.g. in logs or release notes) that the version is major because of a specific earlier PR (e.g. “Major bump due to: PR #X – Breaking Change”).

Additional context

• The release stage uses semantic versioning and conventional commits (or equivalent labels). The version and changelog are derived from all merged PRs since the last release tag, not only the PR that triggered the current build.
• One of those PRs was a breaking change, so a major bump is correct per semver; the issue is the mismatch between expectations (“only this merge”) and actual behavior (“all merges since last tag”) and the lack of visibility into which PR caused the major bump.
• Suggested improvements: (1) Document that “release version = all merged PRs since last tag.” (2) In the release step, log or display which PR(s) drove the bump type (e.g. “Major due to: PR #X – Breaking Change”). (3) Optionally document or support workflows for patch-only releases (e.g. release frequency or branch strategy).