[autonomy-atomicity] Positional rename registry in backwards-compat script is a merge-conflict hotspot

## Autonomy / Atomicity Findings

### 1. Positional parallel arrays in rename routing can silently break mappings
**Category:** Manual routing / registration
**File(s):**
- `scripts/backwards-compat.sh:17-35`
- `scripts/backwards-compat.sh:37-41`
- `Makefile:170-183`

**Problem:**
The rename mapping is maintained as two separate positional arrays (`OLD_NAMES` and `NEW_NAMES`) and joined by index in a loop. This script runs during `make compile`.

When two parallel changes both edit rename mappings, conflict resolution can leave arrays out of sync (reordering, insertion, or deletion in only one array). That can silently generate incorrect old→new compatibility files, creating subtle breakage that is hard to detect in review.

**Suggested fix:**
Refactor to a single source of truth for mappings (e.g., tuple list like `old:new` entries or a small YAML/JSON manifest). Add validation that each mapping entry is complete and fail fast on malformed input before writing compatibility files.

## Suggested Actions
- [ ] Replace positional `OLD_NAMES`/`NEW_NAMES` arrays with a single structured mapping source.
- [ ] Add a validation step that enforces one-to-one mapping integrity before file generation.
- [ ] Add a lightweight test or check that verifies expected old→new output pairs from the mapping source.

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Autonomy Atomicity Analyzer](https://github.com/elastic/ai-github-actions/actions/runs/22962882056)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.