Implement renderer device, frame-graph, and output-target lifecycle

[zoeyrose]

Outcome

Create one explicit device/queue/frame owner with shared passes and safe lifecycle for client windows, editor viewports, and offscreen targets.

Scope and invariants

• Define world opaque/cutout/transparent, lighting/effects, overlay/selection, UI, semantic-mask, and readback passes with declared inputs/outputs.
• Represent window, embedded texture, and offscreen targets behind one bounded API with scale/color/format/sample capabilities.
• Own adapter/device/queue selection, surface acquisition, frame pacing handoff, resize/suspend, transient allocation, command submission, and teardown.
• Recover from surface errors and approved device-loss cases without stale resources or consumer-owned GPU handles.
• Make screenshots/readback asynchronous and bounded so they cannot stall gameplay indefinitely.

Acceptance criteria

• Lifecycle tests repeatedly create multiple targets, resize/suspend/drop them in varied order, inject surface/device failures, and verify resource cleanup.
• Client/editor/offscreen use the same pass graph and material/resource systems.
• Frame errors are typed and tell consumers whether to retry, recreate target, recreate device, or terminate.
• Metrics expose per-pass CPU/GPU time, target size, allocation, submissions, and recovery.
• No renderer-internal state is mutated concurrently without a single explicit owner.

Dependencies and parallelization

Depends on M1 proof. Scene/resource/UI passes can implement in parallel against mock targets after API approval.

Licensing

Rendering code, shaders, tests, and newly authored fixtures are MIT. Reuse from atrinik/classic sources is allowed only through the audited approved-grantor grant; all other behavior is independently implemented. Bundled assets require exact compatible licenses and notices.