## Support plugin ID migrations when a manifest ID changes

The plugin manager currently treats the manifest `id` as the plugin identity, but `omarchy plugin update` updates the checkout by its existing directory:

    ~/.config/omarchy/plugins/<old-id>/

It does not detect or migrate a changed `manifest.json` ID.

### Reproduction

1. Install and enable a plugin with `{ "id": "author.old-name" }`.
2. The user has `author.old-name` in `shell.json` and the checkout at `~/.config/omarchy/plugins/author.old-name/`.
3. Publish an update from the same repository with `{ "id": "author.new-name" }`.
4. Run `omarchy plugin update author.old-name`.

The update fast-forwards the old checkout, but the catalog now indexes the manifest as `author.new-name`. The directory, `shell.json`, enable/disable state, and commands using the old ID are not migrated together.

### Impact

Existing users can end up with an old checkout directory, a new registry ID, a stale `shell.json` entry, and a plugin that appears installed but is not enabled or loaded. Updating with the new ID can fail because the new directory does not exist. Bar placement and plugin configuration may require manual repair.

New users installing the same repository get the new ID, so old and new installations behave differently.

### Suggested direction

Add an explicit migration field to the manifest, for example:

    { "id": "author.new-name", "renamedFrom": ["author.old-name"] }

During update/rescan, the manager could verify the declared migration, migrate the checkout directory, update matching IDs in `shell.json` while preserving placement and settings, migrate enabled/disabled state, refresh the registry, and keep a temporary compatibility alias for old CLI calls.

The migration should be explicit and opt-in so an arbitrary manifest ID change cannot silently take over another installed plugin's configuration.