Add USER root disclaimer to porting sample app guide (#3245)

## Type of change
**Documentation Update**
- Added disclaimer to the `USER root` key point clarifying it is a
temporary escalation only, and that users should switch to a dedicated
non-root user after completing root-level operations

## What should this PR do?

resolves chainguard-dev/internal#4783

## Why are we making this change?

A customer migrating to Chainguard Images interpreted the `USER root`
guidance as a permanent setting rather than a temporary step for
software installation. The updated wording makes clear that containers
should revert to a dedicated non-root user after root-level operations,
preserving the security benefits of minimal images.

## What are the acceptance criteria?

- The "Porting Key Points" bullet on `USER root` explicitly states it is
a temporary escalation
- The bullet advises creating and switching to a dedicated non-root user
(or using the image's built-in non-root user) after root-level
operations
- The disclaimer is clear and actionable without being overly verbose

## How should this PR be tested?

1. Check the preview link and verify the updated bullet point renders
correctly in the "Porting Key Points" section
2. Confirm the disclaimer reads naturally within the existing list

Signed-off-by: Mark Drake <mark@chainguard.dev>

Author: SharpRake

content/chainguard/migration/porting-apps-to-chainguard/index.md

@@ -21,15 +21,15 @@ toc: true
 ### Porting Key Points
 
 * Chainguard's distroless Containers have no shell or package manager by default. This is great for security, but sometimes you need these things, especially in builder images. For those cases we have `-dev` variants (such as `cgr.dev/chainguard/python:latest-dev`) which do include a shell and package manager.
-* Chainguard Containers typically don't run as root, so a `USER root` statement may be required before installing software.
+* Chainguard Containers typically don't run as root, so a `USER root` statement may be required before installing software. This should be a temporary escalation only; after completing any root-level operations, you should create and switch to a dedicated non-root user (for example, using `addgroup` and `adduser`) or use the image's built-in non-root user. Leaving the container running as root defeats the security purpose of using minimal images.
 * The `-dev` variants and `wolfi-base` / `chainguard-base` use BusyBox by default, so any `groupadd` or `useradd` commands will need to be ported to `addgroup` and `adduser`.
 * The [Free tier](/chainguard/chainguard-images/about/images-categories/#starter-containers) of Containers provides `:latest` and `:latest-dev` versions. Our paid Production Containers offer tags for major and minor versions.
 * We use apk tooling, so `apt install` commands will become `apk add`.
 * Chainguard Containers are based on `glibc` and our packages cannot be mixed with Alpine packages.
 * In some cases, the entrypoint in Chainguard Containers can be different from equivalent container images based on other distros, which can lead to unexpected behavior. You should always check the image's specific documentation to understand how the entrypoint works.
 * When needed, Chainguard recommends using a Base Container like `chainguard-base` or a `-dev` variant to install an application's OS-level dependencies.
 * Although `-dev` variants are still more secure than most popular container images based on other distros, for increased security on production environments we recommend combining them with a distroless variant in a multi-stage build.
----
+
 
 ## The Sample Application