eufemia-portal-contentlisted

# Edit Eufemia Portal Content Handle the repository and GitHub workflow for the contributor. Use plain language, show the proposed result, and do not require them to choose branches, commands, files, or validation steps. 1. Read the repository instructions and inspect the current page and nearby content before proposing an edit. Verify technical claims against the source or current Eufemia documentation. 2. Before changing files, ask two plain-language questions: whether the change should appear in the next release notes, and whether it can wait for the next regular portal deployment or needs a portal-only deployment. For an urgent change, also ask for the desired deadline and a short reason that maintainers can evaluate. 3. Fetch current refs and create the content branch from `origin/main`. `main` is the source for new work; `release` is the exact source deployed to the production portal. 4. Keep one independently understandable content outcome per pull request. Split changes that cover different topics, audiences, navigation areas, or reviewer decisions. Keep tightly coupled edits together when separating them would make either preview incomplete or misleading. If the work grows while editing, stop expanding the current pull request and propose the remaining sequence. 5. Preserve the page's MDX structure, imports, links, terminology, tone, and heading hierarchy. Do not turn an editorial request into component, API, or layout w