Repository references from content.xml override user-disabled state on update

[lvostinar]

The Code Flow

1. LocalMetadataRepository.publishRepositoryReferences() — fires a RepositoryEvent.DISCOVERED event for every in content.xml, every time the repository is loaded (not just first time). The enabled flag comes directly from content.xml with no check against existing user preferences.
2. AbstractRepositoryManager.notify() — handles the DISCOVERED event, creates a RepositoryInfo with isEnabled from the event, and calls addRepository(info, true).
3. AbstractRepositoryManager.addRepository(RepositoryInfo, boolean) — has a contains() check that should prevent overwriting existing repos. But this fails when:

• The configuration area changes during a product update (preferences become empty, all repos are treated as new and added with enabled=true from content.xml)
• URI canonicalization mismatch (trailing slash, encoding) — getKey(URI) doesn't match

4. AbstractRepositoryManager.addRepository(URI) (public API) — even more dangerous: if (!addRepository(location, true, true)) { setEnabled(location, true); } — unconditionally re-enables already-known repos.
   Reproduction
5. Install an Eclipse RCP product that defines in its .product file with enabled="true"
6. Disable one of those repositories via Window > Preferences > Install/Update > Available Software Sites
7. Update the product from the update site
8. Observe the disabled repository is re-enabled
   Proposed Fix
   In AbstractRepositoryManager.notify() (or addRepository(RepositoryInfo, boolean)): when processing a DISCOVERED event for a repository URI that is already known to the manager (even if currently disabled), do not override the user's stored enabled state. Only apply the enabled flag from the reference for genuinely new (never-before-seen) repositories.