🏗️ Consolidate mpm.json persistence and remove PluginRepositoryImpl dead code

[Nlkomaru]

Summary

Persistence responsibility for mpm.json and metadata is scattered across multiple classes, and PluginRepositoryImpl appears to be dead code.

Issue 1: Scattered mpm.json persistence

Multiple services directly read/write mpm.json:

• PluginInfoServiceImpl — reads mpm.json (lines 64, 135, 187, 274)
• PluginLifecycleServiceImpl — reads AND writes mpm.json (lines 91, 176-177)
• ProjectRepositoryImpl — reads AND writes mpm.json (lines 42-68)

Both PluginLifecycleServiceImpl and ProjectRepositoryImpl can write mpm.json, creating duplication. Error handling for parse failures is inconsistent across these locations.

Fix: Route all mpm.json reads/writes exclusively through ProjectRepositoryImpl (the proper repository layer). Services should depend on the repository interface, not handle file I/O directly.

Issue 2: PluginRepositoryImpl is dead code

Location: paper/.../infrastructure/persistence/PluginRepositoryImpl.kt

• Registered in Koin (Mpm.kt line 153) but never injected in production code
• Contains a comment/code mismatch: comments say "save in JSON format" but writes to .yaml files while encoding JSON
• Has contradictory format handling vs PluginMetadataManagerImpl which correctly uses YAML

Fix: Remove PluginRepositoryImpl entirely and its Koin registration. If metadata persistence abstraction is needed, redesign it as the single source of truth for metadata.

Impact

• Difficult to maintain and reason about persistence behavior
• Risk of divergent persistence behavior between code paths
• Dead code increases cognitive load