feat(ConfirmationModal): introduce portal prop for DOM relocation

[rubinaga]

ConfirmationButton always renders its modal inside a portal, while ConfirmationModal did not.
This inconsistency caused:

• unpredictable z-index stacking when multiple layered components are open
• difficulty debugging and forcing stacking contexts
• different behaviour depending on whether a developer used the modal directly or via ConfirmationButton

This PR introduces an explicit renderInPortal option and makes both components behave consistently.

Done

• Added renderInPortal prop to ConfirmationModal, allowing consumers to opt-into portal rendering.
• Changed ConfirmationButton to rely on ConfirmationModal's portal behaviour instead of managing its own wrapper.

Updated and expanded unit tests for:

• portal / non-portal rendering

No visual changes to the modal itself.

QA

Pinging @canonical/react-library-maintainers for a review.

QA in your project

from react-components run:

yarn build
npm pack

Install the resulting tarball in your project with:

yarn add <path-to-tarball>

QA steps

• Open ConfirmationModal with and without renderInPortal
• Inspect the DOM using dev tools:
  • When renderInPortal={true}, the modal should appear outside the app root inside a dynamically created portal node.
  • When renderInPortal={false}, the modal should appear inline where it is rendered.

Percy steps

No visual changes expected

[webteam-app]

Demo

Jenkins

demos.haus

[edlerd]

LGTM, keeping defaults as is, so it seems safe to merge.

[edlerd]

@rubinaga please, can you rebase on the latest main to get a clean history for the merge?

[edlerd]

LGTM 👍

[github-actions]

🎉 This PR is included in version 3.11.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀