eufemia-reviewlisted

# Review Eufemia Usage Review against Eufemia's current contract, not local copies of design-system facts. 1. Identify the Eufemia version in the target project. Call `docs_meta` and note any mismatch with the installed version. If they differ, switch to the local MCP from the installed package before reporting version-specific findings. If Eufemia is not installed, state that there is no runtime usage to verify and limit the review to proposed code or documentation. 2. Use `docs_search` and `docs_read` for relevant requirements, recommendations, deprecations, and release guidance. 3. Resolve every questioned component with `component_find`. Verify its current API with `component_props` and behavior with `component_doc`. 4. Call `review_rules`. Run the Eufemia ESLint and Stylelint plugins when they are installed in the target project. Treat their findings according to the same rule metadata and documentation. 5. Classify each finding as unsupported usage, deprecation, accessibility defect, recommendation, or context-dependent alternative. 6. Only propose automatic changes when the replacement is deterministic and preserves behavior. Do not automatically redesign application architecture. 7. Present actionable findings first, with source paths and Eufemia documentation evidence. State remaining test or manual verification gaps. Do not turn preferences into universal Eufemia requirements. Missing generic functionality should be considered for