Add support for updating extension sources and names (#21715)

pr-description.md

@@ -0,0 +1,65 @@
+## Summary
+
+This PR implements a seamless migration path for extensions to move to a new
+repository and optionally change their name without stranding existing users.
+
+When an extension author sets the `migratedTo` field in their
+`gemini-extension.json` and publishes an update to their old repository, the CLI
+will detect this during the next update check. The CLI will then automatically
+download the extension from the new repository, explicitly warn the user about
+the migration (and any renaming) during the consent step, and seamlessly migrate
+the installation and enablement status while cleaning up the old installation.
+
+## Details
+
+- **Configuration:** Added `migratedTo` property to `ExtensionConfig` and
+  `GeminiCLIExtension` to track the new repository URL.
+- **Update checking & downloading:** Updated `checkForExtensionUpdate` and
+  `updateExtension` to inspect the `migratedTo` field. If present, the CLI
+  queries the new repository URL for an update and swaps the installation source
+  so the update resolves from the new location.
+- **Migration & renaming logic (`ExtensionManager`):**
+  - `installOrUpdateExtension` now fully supports renaming. It transfers global
+    and workspace enablement states from the old extension name to the new one
+    and deletes the old extension directory.
+  - Added safeguards to block renaming if the new name conflicts with a
+    different, already-installed extension or if the destination directory
+    already exists.
+  - Exposed `getEnablementManager()` to `ExtensionManager` for better typing
+    during testing.
+- **Consent messaging:** Refactored `maybeRequestConsentOrFail` to compute an
+  `isMigrating` flag (by detecting a change in the installation source). The
+  `extensionConsentString` output now explicitly informs users with messages
+  like: _"Migrating extension 'old-name' to a new repository, renaming to
+  'new-name', and installing updates."_
+- **Documentation:** Documented the `migratedTo` field in
+  `docs/extensions/reference.md` and added a comprehensive guide in
+  `docs/extensions/releasing.md` explaining how extension maintainers can
+  transition users using this feature.
+- **Testing:** Added extensive unit tests across `extension-manager.test.ts`,
+  `consent.test.ts`, `github.test.ts`, and `update.test.ts` to cover the new
+  migration and renaming logic.
+
+## Related issues
+
+N/A
+
+## How to validate
+
+1. **Unit tests:** Run all related tests to confirm everything passes:
+   ```bash
+   npm run test -w @google/gemini-cli -- src/config/extensions/github.test.ts
+   npm run test -w @google/gemini-cli -- src/config/extensions/update.test.ts
+   npm run test -w @google/gemini-cli -- src/config/extensions/consent.test.ts
+   npm run test -w @google/gemini-cli -- src/config/extension-manager.test.ts
+   ```
+2. **End-to-end migration test:**
+   - Install a local or git extension.
+   - Update its `gemini-extension.json` to include a `migratedTo` field pointing
+     to a _different_ test repository.
+   - Run `gemini extensions check` to confirm it detects the update from the new
+     source.
+   - Run `gemini extensions update <extension>`.
+   - Verify that the consent prompt explicitly mentions the migration.
+   - Verify that the new extension is installed, the old directory is deleted,
+     and its enablement status carried over.