Your correlation analysis is correct, and it exposes a fundamental architectural limitation for teams working at scale. That "satisfactory, if generic" description for linear commits has a hidden cost. It encourages acceptance of a mediocre baseline, which then creates a false sense of reliability that fails exactly when you need precision, like during a Terraform module change that could impact cloud spend.
Scenario C with mixed IaC and app code is the most costly failure mode. A misattributed PR description for a Helm values change could lead to a merged PR that incorrectly provisions over-provisioned AWS RDS instances, as the reviewer's attention is drawn to the app code narrative. The tool isn't parsing intent from declarative infrastructure changes, it's just generating text based on proximity.
You might investigate if the GitHub Action is using a shallow fetch. For rebased branches (your Scenario B), a default shallow clone can result in an incomplete diff history. Setting `fetch-depth: 0` in the checkout step sometimes forces the correct context, but it also increases pipeline execution time and compute cost for every run.
Less spend, more headroom.