fix: Issue 681 - Reduce Image Details Repaint Cost On Layer Navigation

[huntharo]

Summary

Related to: #681

This PR is stacked on top of (should be rebased and merged after) #682

This PR is intentionally minimal and includes only one functional change:

• Skip ImageDetails pane re-render when layer navigation does not change image-details view state (same width and same selected/non-selected status).

Scope

Included:

• cmd/dive/cli/internal/ui/v1/view/image_details.go
• cmd/dive/cli/internal/ui/v1/view/image_details_render_cache_test.go

Not included:

• Any filetree comparer/navigation changes
• Any export/CI behavior changes
• Any CLI/API changes

Why This Fix

On every layer move, ImageDetails.Render() was repainting a large static body even though its content is image-level, not layer-level.

For ghcr.io/openclaw/openclaw:2026.2.17, the inefficiency table is very large (~49k rows), so repainting this pane on each arrow press created visible lag.

What Changed

1. Lazily build and cache the image-details body once (preRendered).
2. Skip repaint unless render state changes:

• pane width changed, or
• pane selection/focus state changed, or
• first render.

Tests

Added unit tests:

• TestImageDetailsShouldRenderOnFirstRender
• TestImageDetailsShouldRenderWhenLayoutOrSelectionChanges

Validated related behavior still passes:

• go test ./cmd/dive/cli/internal/ui/v1/view -count=1
• go test ./cmd/dive/cli/internal/command/export -count=1
• go test ./cmd/dive/cli/internal/command/ci -count=1

Performance Notes (Layer 1 -> Layer 2 transition)

Measured with targeted profiling of the image-details render work.

Baseline (unmodified code at issue-681/image-details-performance):

• Slow image (2026.2.17):
  • inefficiency rows: 49253
  • image-details body size: 5821237 bytes
  • per-transition image-details render work:
    • first sample: 21.316417ms
    • average over 20 runs: 18.305254ms
• Fast image (2026.2.21):
  • inefficiency rows: 158
  • image-details body size: 8519 bytes
  • per-transition image-details render work:
    • first sample: 68.375µs
    • average over 20 runs: 52.133µs

With this PR:

• Layer 1 -> 2 navigation does not repaint ImageDetails when width/focus are unchanged.
• Effective image-details render cost for that transition is eliminated (skipped path).

Repro Steps

0) Test #682 branch with test case images as baseline

2026.2.17 - Image with problem chown layer

Once the UI loads (~40 seconds), press the down arrow in the layer tab (default focus) once. It should move to the next layer in ~1 second. If it takes > 5 seconds you may be using main or a branch that does not have the first fix that resolves teh 10+ second layer switch time. Once confirming you have the correct image, press down arrow 5 times quickly and observe that the UI will jump to the fifth layer after about a 1 second pause. This is the problem.

./.tmp/dive ghcr.io/openclaw/openclaw:2026.2.17

2026.2.21 - Image without the problem chown layer

Once the UI loads, press the down arrow five times rapidly. The UI should update and move to the next layer before you can press the arrow key again. There will not be a jump of 5 layers in one move.

./.tmp/dive ghcr.io/openclaw/openclaw:2026.2.21

1) Build this PR branch

go build -o .tmp/dive ./cmd/dive

2) Test with image that has no issue (control)

./.tmp/dive ghcr.io/openclaw/openclaw:2026.2.21

Action: press Down from layer 1 to 2 repeatedly.
Expected: immediate navigation, no jumping 5 layers if you press down arrow 5 times rapidly, no hangs

3) Test with image that showed issue

./.tmp/dive ghcr.io/openclaw/openclaw:2026.2.17

Action: press Down from layer 1 to 2 repeatedly.
Expected: immediate navigation, no jumping 5 layers if you press down arrow 5 times rapidly, no hangs

Risk

Low:

• Change is isolated to image-details view repaint gating.
• No changes to efficiency computation, export payloads, or CI evaluation logic.