When an organization consolidates workflow statuses (e.g., remapping "Ready for Development" to "Selected for Development" and removing the old status), the Sprint Report and Velocity Chart incorrectly flag affected issues as scope changes/added after sprint start, even when those issues were added to the sprint well before the start date.

Steps to Reproduce:

1. Have a Scrum board with active and completed sprints containing issues

1. Consolidate workflow statuses by updating workflows to replace one status with another (e.g., replace "Status A" with "Status B") and removing the old status

1. Jira logs a changelog event for each affected issue as it repoints to the new status

1. Navigate to the Sprint Report for any sprint (current or historical) on that board

1. Observe that the majority of issues are now marked with an asterisk ("issue added to sprint after start time")

1. Check the Velocity Chart and observe that "Completed" is significantly higher than "Committed"

Expected Result:
Sprint Reports and Velocity Charts should not be affected by workflow status consolidation operations. Issues that were legitimately added to a sprint before the start date should not be flagged as scope changes.

Actual Result:
The Sprint Report engine interprets the changelog events generated by the status remapping as "issue moved into board from an unmapped status," treating them as scope additions. This affects both current and historical/completed sprints retroactively.

Impact:

• Organizations performing status consolidation or workflow standardization (common during site merges, process alignment, or governance cleanup) lose the accuracy of all sprint reporting during and after the migration

• There is no workaround to filter out these events

• Historical sprint data cannot be corrected after the fact