dhi: feedback followup (#22859)

<!--Delete sections as needed -->

## Description

Update DHI docs based on internal feedback.

## Related issues or tickets

ENGDOCS-2739

## Reviews


- [ ] Editorial review

Signed-off-by: Craig <craig.osterhout@docker.com>

content/manuals/dhi/about/available.md

@@ -34,8 +34,8 @@ requirements:
   many language ecosystems and enterprise systems.
 
 - Alpine-based images: A smaller and more lightweight option using musl libc.
-  These images are faster to pull and have a reduced footprint, though you may
-  need to account for musl-glibc differences in some applications.
+  These images tend to be small and are therefore faster to pull and have a
+  reduced footprint.
 
 Each image maintains a minimal and secure runtime layer by removing
 non-essential components like shells, package managers, and debugging tools.
@@ -52,8 +52,8 @@ with. Debian tends to offer the broadest compatibility.
 
 ## Development and runtime variants
 
-To accommodate different stages of the application lifecycle, DHI offers images
-in several variants:
+To accommodate different stages of the application lifecycle, DHI offers all
+language framework images and select application images in two variants:
 
 - Development (dev) images: Equipped with necessary development tools and
 libraries, these images facilitate the building and testing of applications in a

content/manuals/dhi/about/test.md

@@ -23,7 +23,7 @@ The testing process for DHIs focuses on two main areas:
 - Image standards compliance: Ensuring that each image adheres to strict size,
   security, and compatibility standards.
 - Application functionality: Verifying that applications within the images
-  function correctly and meet expected performance benchmarks.
+  function correctly.
 
 ## Image standards compliance
 
@@ -33,8 +33,8 @@ Each DHI undergoes rigorous checks to meet the following standards:
   unnecessary components to reduce potential vulnerabilities.
 - Near-zero known CVEs: Images are scanned using tools like Docker Scout to
   ensure they are free from known Common Vulnerabilities and Exposures (CVEs).
-- Multi-architecture support: DHIs are built for multiple architectures,
-  including `linux/amd64` and `linux/arm64`, to ensure broad compatibility.
+- Multi-architecture support: DHIs are built for multiple architectures
+  (`linux/amd64` and `linux/arm64`) to ensure broad compatibility.
 - Kubernetes compatibility: Images are tested to run seamlessly within
   Kubernetes clusters, ensuring they meet the requirements for container
   orchestration environments.

content/manuals/dhi/about/what.md

@@ -77,9 +77,9 @@ so you don’t have to.
   environment while maintaining compatibility with common Linux distributions.
   They remove non-essential components like shells and package managers to
   enhance security, yet retain a small base layer built on familiar distribution
-  standards. You can choose between Alpine-based images (using musl libc) and
-  Debian-based images (using glibc) to suit your application's compatibility
-  requirements.
+  standards. Images are typically available with musl libc (Alpine-based) and
+  glibc (Debian-based), supporting a broad range of application compatibility
+  needs.
 
 ## Why use Docker Hardened Images?
 
@@ -87,7 +87,7 @@ Docker Hardened Images (DHIs) are secure by default, minimal by design, and
 maintained so you don't have to. They offer:
 
 
-- Images built for peace of mind: Ultra-minimal and distroless, DHIs eliminate up to 95 percent of the traditional container attack surface.
+- Images built for peace of mind: Ultra-minimal and distroless, DHIs eliminate up to 95% of the traditional container attack surface.
 - No more patch panic: With continuous CVE scanning and SLA-backed remediation, Docker helps you stay ahead of threats.
 - Audit-ready images: All DHIs include signed SBOMs, VEX, and provenance that support security and compliance workflows.
 - Images that work with your stack: Available in Alpine and Debian flavors, DHIs drop into your existing Dockerfiles and pipelines.

content/manuals/dhi/how-to/mirror.md

@@ -158,6 +158,21 @@ $ docker push registry.example.com/my-project/<image>:<tag>
 > To continue receiving image updates and preserve access to Docker Hardened
 > Images, ensure that any copies pushed to other registries remain private.
 
+### Include attestations when mirroring images
+
+Docker Hardened Images are signed and include associated attestations that
+provide metadata such as build provenance and vulnerability scan results. These
+attestations are stored as OCI artifacts and are not included by default when
+using the Docker CLI to mirror images.
+
+To preserve the full security context when copying DHIs to another registry, you
+must explicitly include the attestations. One tool is `regctl`, which supports
+copying both images and their associated artifacts.
+
+For more details on how to use `regctl` to copy images and their associated
+artifacts, see the [regclient
+documentation](https://regclient.org/cli/regctl/image/copy/).
+
 ## What's next
 
 After mirroring an image repository, you can you can start [using the