fix(plugins): stop creating a stray Application%20Support folder for the registry cache

[datlechin]

Summary

• The plugin registry cache uses URLCache(memoryCapacity:diskCapacity:diskPath:). On macOS 15 and earlier the directory: initializer opens the cache at the percent-encoded path (FB9117600), which created ~/Library/Application%20Support/TablePro/Registry/URLCache.
• New RegistryStorageSweep, run after launch in production, removes:
  • the misplaced cache, then each encoded parent it left empty (a .DS_Store counts as empty). It never touches an ancestor of the real path and does nothing when the path has nothing to encode.
  • TablePro/Registry/registry-manifest.json, which 0.81 wrote and feat(plugins): read the v3 plugin manifest from updates.tablepro.app #3503 stopped reading.
  • ~/Library/Caches/<bundle id>/registry-manifest.json, the pre-0.55 location whose migration feat(plugins): read the v3 plugin manifest from updates.tablepro.app #3503 dropped.
  • the registry defaults keys nothing reads since feat(plugins): read the v3 plugin manifest from updates.tablepro.app #3503 (com.TablePro.registryLastFetch, com.TablePro.customRegistryURL, and the pre-0.40 keys).
• apple/scripts/probes/check-urlcache-directory-path.sh reports where each initializer puts Cache.db.

Test plan

• RegistryStorageSweepTests: the cache under a root with a space opens at the file-system path; the sweep removes the misplaced tree and empty encoded parents, keeps a parent holding other files, leaves a cache whose path has nothing to encode, and removes the retired manifests and keys while keeping the others.
• The cache location test also passes on main on macOS 27, which CI runs, because the bug is gone there. It can fail on main only on macOS 15 and earlier; no such Mac was available here.
• Probe on macOS 27.0.1: both initializers write to the real path.

Fixes #3676