Define canonical identity for imported extensions

**What problem would this solve?**

Imported extension mappings can contain an outer configuration key and an embedded extension name that disagree. Different listing, lookup, enablement, and removal paths currently treat different values as authoritative, making compatibility and mutation behavior ambiguous.

**What would a good outcome look like?**

Every extension has one stable identity across import, display, lookup, enable, disable, removal, and session startup. Existing mismatched configurations have an explicit migration or rejection path, and collisions cannot silently select or retain a different executable extension.

**Possible approaches**

- Reject mismatched mappings during import and parsing.
- Canonicalize and migrate legacy mappings with collision checks and clear diagnostics.
- Preserve raw storage IDs internally while exposing an immutable separate canonical ID.
- Define how built-ins, normalized aliases, and duplicate embedded names interact.

**Additional context**

Acceptance tests should cover lookup precedence, failed-revocation cases, legacy migration or rejection, collisions, and both legacy and state-machine session startup.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).