[BUGFIX] Load explorer plugins from the configured plugins base URL

[Yash121l]

Description

Fixes perses/perses#4455

When Perses is served under an api_prefix, for example /perses, every explorer plugin fails with PluginLoaderComponent: Error loading plugin XXXExplorer from module XXX. The mf-manifest.json request goes to /plugins/Tempo/mf-manifest.json instead of /perses/plugins/Tempo~0.59.0/mf-manifest.json.

Two things combine to cause it:

1. ExploreManager builds the PersesPlugin it hands to PluginLoaderComponent with only name and moduleName. The module version and registry are available on currentPlugin.module but get dropped, so the remote entry path loses its version and registry suffix.
2. registerRemote in PluginRuntime falls back to a hardcoded /plugins when a plugin carries no baseURL. remotePluginLoader is already configured with the right assets path, since the app passes api_prefix into it, but nothing shares that with plugins loaded through PluginLoaderComponent, which bypasses PluginRegistry.

Datasource, panel and query plugins are unaffected because they go through remotePluginLoader.importPluginModule, which threads baseURL, version and registry correctly.

Changes

• ExploreManager passes version and registry from the plugin's module metadata, matching what remotePluginLoader does.
• PluginRuntime keeps the assets base URL the plugin loader was configured with and uses it as the fallback instead of the hardcoded /plugins. A plugin's own baseURL still wins.
• remotePluginLoader registers its resolved pluginsAssetsPath with the runtime.

I kept window.PERSES_APP_CONFIG out of it, which the issue offers as an alternative, since this repository should not depend on product-specific globals. Reading the path the loader was already given keeps the configuration in one place and fixes any consumer of PluginLoaderComponent, not only the explorer.

Worth noting: the issue is filed on perses/perses and quotes ui/explore/... paths, but those packages moved here in perses/perses#3659, so this is where the fix belongs. The field names in the issue's suggestion are also slightly off, module is itself the metadata object, so the values are module.version and module.registry.

Verification

Added a test in PluginRuntime.test.ts asserting the manifest entry uses the loader's configured base URL, and one in ExploreManager.test.tsx asserting the plugin object carries the module's version and registry. Both fail without the change; the first fails with exactly the URL from the bug report. All five workspace suites pass (1216 tests), along with lint, format check, type check, build and make checklicense.

Screenshots

No visual change. The fix is in the URL used to fetch plugin manifests.

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.