bug: Double counting of potential space savings in inefficiency report

What happened: For images with duplicated files across layers, the reported Potential wasted space is overstated (appears to count all copies), while the efficiency percentage suggests only removable duplicates are counted.

Example:

• ghcr.io/openclaw/openclaw:2026.2.17
• ghcr.io/openclaw/openclaw:2026.2.21

For 2026.2.17, there is an extra ~900 MB chown layer that duplicates most files from a ~970 MB pnpm install layer. The UI reports:

• Total image size: ~3.2 GB
• Potential wasted space: ~1.8 GB
• Efficiency: ~71%

The 71% efficiency implies ~29% waste (~900 MB of 3.2 GB), but the wasted-bytes value shows ~1.8 GB (double-reporting reclaimable space).

What you expected to happen: Potential wasted space should represent only reclaimable duplicate bytes:

• If a file path has 1 copy: reclaimable = 0
• If a file path has 2 copies: reclaimable = 1 copy
• If a file path has N copies: reclaimable = N-1 copies

So in this case, expected wasted space is roughly the duplicate layer size (~900 MB), not both copies (~1.8 GB).

How to reproduce it (as minimally and precisely as possible):

1. Pull or analyze image ghcr.io/openclaw/openclaw:2026.2.17.
2. Open it in dive and check the image details/inefficiency section.
3. Observe:
   • An extra chown layer (~900 MB) that duplicates files from a pnpm install layer (~970 MB).
   • Reported potential wasted space is ~1.8 GB.
4. Compare with efficiency percentage (~71%), which corresponds to ~900 MB reclaimable from a ~3.2 GB image.

Anything else we need to know?: This appears in duplicate-heavy layer patterns (e.g., copy/chown of existing content). The percentage metric and byte metric become inconsistent in these cases.

Environment:

• OS version: macOS 26.2
• Docker version (if applicable): Engine 29.2.1