Changelog tool mislabels added operation group classes as Added model

[msyyc]

Context

The changelog generation tool at scripts/breaking_changes_checker mislabels newly added operation group classes as models.

When a management-plane SDK adds a new operation group (e.g. PrivateLinkResourcesOperations), the changelog currently produces:

- Client `AttestationManagementClient` added operation group `private_link_resources`
- Added model `PrivateLinkResourcesOperations`

The second line is wrong — PrivateLinkResourcesOperations is an operation group, not a model. Today this has to be manually corrected in a post-generation optimization step to:

- Client `AttestationManagementClient` added operation group `private_link_resources`
- Added operation group `PrivateLinkResourcesOperations`

Root cause

In scripts/breaking_changes_checker/changelog_tracker.py, run_non_breaking_class_level_diff_checks() classifies every newly added class into one of three branches: client, enum, or else → Added model (ADDED_CLASS_MSG). Operation-group classes fall into the else branch and are labeled as models.

The correct concept already exists (ChangeType.ADDED_OPERATION_GROUP), but it is only used for the client property line (Client X added operation group ...), never for the operation-group class itself.

Proposed fix

Detect operation-group classes in the new-class branch and emit a dedicated message instead of Added model:

• Add ADDED_OPERATION_GROUP_CLASS_MSG = "Added operation group {}" and a corresponding ChangeType.
• In the new-class else branch, treat a class as an operation group when its name ends with operations (case-insensitive, covers both FooOperations and the default Operations) and it is defined in an operations module (module name ends with operations), consistent with the existing attr_type.lower().endswith("operations") convention used elsewhere in the tool.
• The existing async cleanup (run_async_cleanup) already collapses the sync/aio duplicates since its dedup key excludes the module name.

This makes the generated changelog correct out of the box and removes the need for the manual "Added model → Added operation group" optimization step.

Acceptance criteria

• Adding a new operation-group class produces Added operation group X instead of `Added model `X.
• No duplicate entry across sync/async modules.
• A unit test covering the scenario in tests/test_changelog.py.