fix(plugins): refetch the registry manifest before install/update (#1380)

[datlechin]

Problem

A user updated to v0.44.0 and got "Plugin Installation Failed" when installing a plugin; quitting, reopening, and reinstalling fixed it. The "restart fixes it" signature points at stale in-memory state, not a bad binary.

Root cause

Registry installs resolve the binary against a manifest that can be stale:

• RegistryClient loads the on-disk cached manifest into memory at launch, and that cache (plus the ETag) survives an app update.
• The install paths (installMissingPlugin, Browse install, manual update, reconciliation) used fetchManifest() without forcing a refresh. On a 304, a CDN-cached copy, or a network blip, fallbackToCacheOrFail keeps the stale in-memory manifest, so the install runs against the pre-update plugin list.
• Even fetchManifest(forceRefresh:) only dropped the If-None-Match header; it never set a cache policy, so URLSession's local cache could still return a stale body.

A restart "fixes" it only because it eventually triggers a fresh fetch.

Fix

• RegistryClient.fetchManifest(forceRefresh:) now sets request.cachePolicy = .reloadIgnoringLocalCacheData, so a forced refresh genuinely bypasses the local URL cache (the documented AppKit/Foundation way; no cache-busting query hacks).
• One chokepoint: installFromRegistry and updateFromRegistry refetch the manifest and re-resolve the plugin by id before validating compatibility, via RegistryClient.refreshedPlugin(matching:). Every install/update path (connect-to-install, Browse, manual update, reconciliation) now resolves against the current manifest. Offline still falls back to the cached manifest, where the existing strict version + checksum checks turn a mismatch into a clear error instead of a wrong install.

Tests

• makeManifestRequest(forceRefresh:) is extracted and unit-tested: forced refresh sets the reload cache policy and sends no If-None-Match.

Logic-only, no new user-facing strings.