[BUG] Marketplace plugin sync permanently blocked by PNG compression ratio false positive — stale server-side cache prevents recovery

Description

Custom marketplace plugin sync fails permanently with "Suspicious compression ratio" error on a PNG file. The error persists indefinitely (3+ days) because:

1. The server-side cache serves stale plugin content regardless of repo updates
2. The failed download of ONE plugin blocks sync for ALL plugins in the marketplace
3. The marketplace cannot be removed (Remove action doesn't persist — marketplace reappears on tab switch/restart)
4. Even renaming the GitHub repo and creating a fresh repo with the same name doesn't help — the server-side cache is tied to the marketplace registration, not the repo

Error

[SkillsPlugin] Failed to download triangility-pptx: Suspicious compression ratio for
"triangility-pptx/assets/logos/Logo_dklgrau.png": 65:1 (max: 50:1)
[SkillsPlugin] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned

Root Cause Analysis

The PNG in question is a logo (1000x309px, RGBA) with large flat-color areas. As a PNG, it compresses very efficiently (1.24 MB raw pixel data → 15 KB file). The ZIP bomb protection appears to compare raw pixel dimensions against file size, not actual ZIP compression ratio. This means any well-compressed PNG with flat colors will trigger the check — even though it poses zero ZIP bomb risk.

The actual ZIP compression ratio (file-in-ZIP vs file-on-disk) is ~1:1 (5.7%), which is completely normal.

Steps to Reproduce

1. Create a custom marketplace with a plugin containing a PNG logo that has large flat-color areas (e.g., a corporate logo with transparency)
2. The PNG should be ~1000x300px, RGBA, with solid color fills — results in ~15-30 KB at optimal compression
3. Push to the marketplace repo
4. Claude Desktop will fail to sync with "Suspicious compression ratio" error

Attempted Fixes (none worked)

| Attempt | Result |
|---------|--------|
| Re-save PNG with lower compression (compress_level=1, 30 KB, ratio 40:1) | Server still serves cached old file (65:1) |
| Rename the PNG file (Logo_dklgrau.png → logo_dark.png) | Server still serves old file under old name |
| Resize PNG to 500x155 (ratio 17:1) | Server cache unchanged |
| Delete old plugin version directories from repo | No effect |
| Remove plugin from marketplace.json entirely | Server still tries to download it |
| Rename GitHub repo + create fresh repo with same name (new repo ID) | Server cache tied to marketplace registration, not repo |
| Create entirely new repo with different name | Works for NEW plugins, but existing plugins still reference old marketplace |
| Clear local Claude Desktop caches (Cache/, Session Storage/, blob_storage/) | No effect |
| Restart Claude Desktop | No effect |
| Remove marketplace via UI | Doesn't persist — marketplace reappears on restart |

Expected Behavior

1. PNG ratio check should use actual ZIP compression ratio, not raw pixel data vs file size
2. Server-side cache should refresh when the source repo is updated (within minutes, not days/never)
3. One plugin's download failure should not block ALL other plugins in the same marketplace
4. Marketplace Remove should actually remove the marketplace permanently

Environment

• Claude Desktop v1.3109.0, macOS
• Custom marketplace: private GitHub repo in an organization
• Plugin with ~15 KB PNG logo (1000x309px RGBA)

Impact

• All 19 plugins in the marketplace are blocked from syncing
• All team members in the organization are affected (server-side cache is shared)
• The issue has persisted for 3+ days with no sign of automatic resolution
• Workaround: created a second marketplace repo with a different name, but existing plugins still reference the old (broken) marketplace

Related Issues

• #39400 — Marketplace plugins fail to load skills in Cowork (zip upload works)
• #38429 — RemotePluginManager removes 3rd-party GitHub marketplace plugins on every sync
• #40600 — Personal marketplace plugin installation lost after restart