IRenderSettingSink

Everything a resolved setting can do to the render side, as an interface.

In the namespace construct::settings. Declared in src/libs/libconstruct/construct/settings/RenderSettingSink.hpp.

Detailed description

Why this exists

`ConstructShell` relays settings to its layers through seventeen per-signal handlers, each of the shape `if (m_sdfLayer) { m_sdfLayer->setX(v); }`. §SS-IM-Deferred wants those replaced by one `applyResolvedSetting(id, value)`, and could not do it: the thirteen suites covering this area all assert that the three surfaces *resolve* the same values, and **none asserts that a layer ever received one**. The layers are GPU objects with no observable seam, so inverting seventeen handlers would have swapped a working relay for an unverified one.

This is that seam. The live implementation forwards to the real layers; a test implementation records the calls. Both go through applyResolvedSetting(), so a test can finally state the thing that mattered all along — *this id reaches that layer call, carrying this value, in these units.*

Why every method is pure

A default no-op body would let an implementation forget a setting silently, which is the failure mode this whole spec exists to remove. Pure virtuals mean adding a routable setting fails to compile until every sink — live and recording — has said what it does about it.

Units are engine units, always

A sink receives what the field means, never what a slider showed: `stepScale` 0.69 and not 69, `exposure` in EV. applyResolvedSetting() is the conversion boundary, and `testRenderSettingSink` pins it — this is the same family as the two writers that put a stepScale of 69 in documents (§SS-IM-8.5).