rendering: retain prepared instance submissions

[tritao]

Builds on #75.

Purpose

The retained renderer already keeps geometry and render plans alive between
frames, but its instanced submission data was still rebuilt and uploaded in
full on every update. This made a small edit in a large repeated assembly much
more expensive than the edit itself: moving one occurrence could require
reprocessing every occurrence before drawing the frame.

This PR keeps the prepared visual instance batches and their OpenGL buffers
alive for as long as their render-plan membership remains valid. A transform
or legacy diffuse-color edit can then update only the instance records for the
commands that actually changed.

The optimization is deliberately conservative. The draw list publishes only
the most recent committed command patch. If the backend missed that revision,
or if the plan, resources, visibility, or an unsupported part of the scene
changed, it refreshes or rebuilds the affected data instead of assuming that
the cached batches are still correct.

Picking and selection continue to use their own transient instance buffer, so
this does not change their ordering or identity semantics.

What changed

• Retain visual instance batches and their GPU buffers across eligible frames.
• Patch and upload only changed instance records.
• Fall back to a full comparison or rebuild when incremental reuse cannot be
  proven safe.
• Report prepared batches and rebuilt, patched, and uploaded records through
  the existing opt-in renderer statistics and benchmark JSON.
• Exercise resource ownership across repeated OpenGL context shutdown and
  recreation.

Performance

The representative case is a staged assembly with 50,000 occurrences, where
one occurrence moves per sample. On the pinned 5.4 GHz performance core:

	Before	This PR
CPU render time	18.6–19.0 ms	1.1–1.2 ms
Instance records rebuilt	all	0
Instance records patched	—	2
Instance records uploaded	all	2

The optimized path still submits 40 draw calls, does not rebuild the retained
frame, and produces the same pixels as a forced rebuild.

These are comparison measurements from one controlled machine, not CI timing
thresholds. The counters and output parity are the deterministic performance
contract.

Validation

• Release build with -j12 and all 34 CTest tests.
• Core and compatibility OpenGL profiles.
• Staged transform and material update batches of 1, 10, and 100.
• Picking, selection, workload parity, viewer smoke, and benchmark smoke.
• A 10,000-frame lifecycle stress test that mixes transform, material, and
  visibility changes with periodic picking and forced-rebuild comparisons.
• Four OpenGL context teardown/recreation cycles during each stress run.