Follow-ups to the Tonemapping::None change

[stuartparmenter]

Objective

In #25499 we made Tonemapping::None a full passthrough and added Tonemapping::Linear for the identity curve. Almost nobody wants a passthrough outside of HDR display calibration. None combined with dither or grading is almost certainly a bug. The defaults and the docs should reflect that.

There was a helpful comment on Discord pointing out that a project upgrading from 0.19 sees the change with no feedback. Camera3d turns dither on by default and Camera2d defaulted to None, so a camera that used None in 0.19 quietly loses dither or color grading in 0.20, and nothing tells the user why or what to do about it (besides the migration guide).

Solution

Add a warning when a camera combines None with dither or grading, so the user finds out when their app runs.

Change Camera2d's tonemapping from None to Linear. In 0.19 the 2D default still applied dither and grading, so Linear matches prior behavior (except that a Camera2d with Hdr now runs the tonemapping pass, which 0.19 did not).

Testing

The warning fires once per camera for bad combinations.

---

This PR was built by me with the assistance of Claude Code w/ Fable 5.1

[cookie1170]

i think a warning for this will definitely be helpful and should be kept, but i think a breaking change like that should break old code, rather than silently make its behaviour incorrect. i think calling Tonemapping::None something like Tonemapping::Disabled, so it doesn't conflict with the old Tonemapping::None name would be better.
although maybe people who didn't read the migration guide would just think it's a pointless rename so it might not be that good of an approach 🤔

[stuartparmenter]

i think a warning for this will definitely be helpful and should be kept, but i think a breaking change like that should break old code, rather than silently make its behaviour incorrect. i think calling Tonemapping::None something like Tonemapping::Disabled, so it doesn't conflict with the old Tonemapping::None name would be better. although maybe people who didn't read the migration guide would just think it's a pointless rename so it might not be that good of an approach 🤔

I debated renaming Tonemapping::None in the previous patch, but it felt like None is the right thing to be None and like a non-standard thing to drop it and use something else.

[cookie1170]

I debated renaming Tonemapping::None in the previous patch, but it felt like None is the right thing to be None and like a non-standard thing to drop it and use something else.

yeah, makes sense