feat(core): implement cross-platform micro-plugin architecture framework (shared/server/desktop/web)

[zhoulujun]

📝 Problem / use case *

Currently, VistaRemote's core business logic (such as file transfer, terminal access, and enterprise auditing) is tightly coupled within the main workspace applications (server, desktop, web). As a high-velocity open-source ecosystem under the VibeCode organization, this monolithic approach introduces several critical engineering bottlenecks:

1. High Contribution Friction: External community developers cannot extend system capabilities or inject domain-specific tools (e.g., specialized AI auditing adapters, virtual game controllers) without heavily refactoring the core codebase.
2. Enterprise Customization Block: We lack a standardized extension sandbox, preventing corporate clients from deploying proprietary, air-gapped security protocols or industry-specific telemetry compliance rules.
3. Repository Architecture Bloat: Forcing every specialized feature into the Meta-Repo ruins compilation velocities and introduces heavy dependency-hoisting risks across Electron, React, and NestJS runtimes.

---

🚀 Proposed solution *

Introduce a unified, decoupled, runtime-injected Cross-Platform Micro-Plugin Framework. The architecture utilizes our flat Meta-Repo layout to implement a "Core-as-Infrastructure, Feature-as-Plugin" strategy across 3 distinct architectural boundaries:

1. Protocol Core (shared)

• Role: The Single Source of Truth for plugin communication.
• Implementation: Establish standard plugin manifest specifications (PluginManifest) and cross-platform lifecycle hooks/interfaces via pure TypeScript contracts. This ensures that any plugin built by the community strictly adheres to VistaRemote's data schemas.

2. Backend Engine (server - NestJS)

• Role: Dynamic routing and event orchestration.
• Implementation: Implement a decoupled PluginManagerService inside NestJS. It uses Node.js dynamic import() to scan, hot-load, and orchestrate external JavaScript bundles out of a designated /plugins directory without polluting core boot routing or breaking the Fastify underlying layer.

3. Frontend Runtime (web / desktop)

• Role: On-demand UI component injection.
• Implementation: Configure Module Federation via Rsbuild / Rspack on the Host UI workspace. Establish strict layout slots (PluginSlot) to securely fetch and isolate remote or local plugin React components at runtime, enabling instant interface extension without client re-compilation.

---

🛠️ Detailed Implementation Checklist

• Phase 1 (shared): Create plugin-types.ts defining PluginManifest, ServerPluginLifecycle, and standard execution permission arrays.
• Phase 2 (server): Build PluginManagerModule with dynamic system directory scanning, error-boundary sandboxing, and hot-loading hooks.
• Phase 3 (web & desktop): Update rsbuild.config.ts to support @module-federation/enhanced as Host, and expose generic UI mounting layout slots (PluginSlot).
• Phase 4 (Validation): Create a standalone test-plugin containing minimal server logs and a mock React dashboard to evaluate end-to-end rendering capability via Playwright integration smoke tests.

---

📌 Additional context

• Tech Stack Bounds: React 19, NestJS 11+, Electron, Rsbuild (Rspack), Vitest.
• Architectural Compliance: All cross-repo commits related to this issue must respect the deterministic sequence rule: shared ──> server ──> frontend primitives (web / desktop).