Change Requests can silently overwrite concurrent changes on commit

### Summary
On v2 feature versioning a Change Request captures the overrides it touches when created. Another CR can then change those overrides and publish. That makes the first CR stale but it can still be committed. On commit it reverts the newer changes back to its captured values. The only feedback is a passive notice that a change request was published since this one was created.

### Reproduction
1. Create a CR that only reorders segment override positions on a feature.
2. Have another CR change the value or enabled state of one of those overrides and publish it.
3. Commit the reorder CR.
4. The concurrent change is reverted. Only a passive warning shows.

### Notes
- Stale detection already exists. It runs on scheduled publishes and blocks them on conflict. It looks like a manual commit skips it.
- A reorder captures each moved override's full state, not just its position. That is why it reverts unrelated fields.

### Requested outcome
- Run the existing conflict check on manual commits too. Flag the CR as out of date. Notify the author. Block the commit or require a refresh first.
- A reorder should only change ordering.
- The diff should separate the author's edits from values that were only carried along.

Start by tracing the existing conflict check used by scheduled publishes and compare it with the manual commit path. Reproduce the two-CR scenario, then verify that manual commits detect stale requests, notify the author, and block or require refresh; also confirm that reordering does not revert unrelated override fields.

Written by the indexing model from the issue text.