[CI] Validate local Penpot MCP runtime

[egdev6]

Summary

Validate the local Penpot MCP runtime against the self-hosted Penpot instance so we can confidently build the design-system workflow on top of a real, working bridge.

Scope

• start and verify local MCP runtime
• verify connection from MCP to local Penpot
• validate execute_code
• validate export_shape
• verify whether import_image works in local mode
• define the local Penpot custom patch strategy before adding new MCP tools
• document findings and blockers

Acceptance Criteria

• MCP is running locally against the self-hosted Penpot instance
• at least one execute_code call succeeds
• at least one shape export succeeds
• the result is documented with explicit supported/unsupported capabilities

Tasks

• confirm local MCP setup and startup command
• verify connection to local Penpot instance
• run a minimal execute_code example successfully
• export a real board or shape successfully
• verify whether import_image is available in local mode
• document which Penpot areas may be customized locally and which areas should remain untouched
• define where design-system MCP tools should live in the Penpot source tree
• document how to keep the local Penpot patch small, reviewable, and easy to rebase against upstream
• document the upgrade review process for future Penpot versions
• document findings and limitations in the repo

Additional notes

This issue is the confidence gate before adding MCP-specific tools for design-system automation.

The patch strategy is intentionally part of this validation gate: before implementing list_pages_and_boards, batch_export_page, or component_structure_report, we need a clear rule for how local Penpot customizations are isolated and maintained. The preferred approach is to keep changes inside the existing MCP area whenever possible, avoid touching Penpot core unless strictly necessary, and document every local customization so future upstream upgrades remain manageable.