Persistent per-output shader / color filter (grayscale, invert, night tint)

[yabo-boye]

Problem

There's currently no way to apply a screen-wide color filter in niri —
grayscale, color inversion, or a strong fixed color tint. This is a
common accessibility/eye-strain feature: GNOME ships it as "Color
Filters" under Accessibility, Hyprland ships it via
decoration:screen_shader (and the community hyprshade tool built
on top of it). Both work without any HDR or color-management
infrastructure — they're a flat shader pass over the composited frame.

wlr-gamma-control-unstable-v1 (used by wlsunset, wl-gammarelay-rs)
can't do this: it's a per-channel 1D LUT, so it can shift temperature
but can't mix R/G/B into luminance the way grayscale requires. True
color management (discussed in #1128) would solve it eventually, but
that's tied to HDR/CTM work that's explicitly on hold pending
cosmic-comp.

Proposal

niri already has a custom-shader mechanism for window animations
(window-open, window-close, window-resize, with
open_color()/close_color()/resize_color()). Could that same
GLSL hook be exposed at the output level as a persistent filter,
toggleable via IPC/keybind, rather than only firing during a window
animation? Something like:

output "eDP-1" {
color-filter {
custom-shader r#"
vec4 filter_color(vec3 coords, vec4 color) {
float gray = dot(color.rgb, vec3(0.2126, 0.7152, 0.0722));
return vec4(vec3(gray), color.a);
}
"#
}
}

or a toggle action (niri msg action toggle-output-color-filter)
bound to a key, similar to how toggle-overview works today.

Why this instead of waiting for full color management

This sidesteps HDR/CTM entirely — it's a post-process effect, not a
color-accuracy feature, so it doesn't need to wait on the DRM Color
Pipeline API or cosmic-comp's implementation. The rendering
infrastructure (GLSL shader compilation, fallback on compile error)
already exists in niri for the animation shaders; this would be
reusing it in a new location rather than building something new.

Use case for context

I run niri on an Intel HD 4000 laptop off-grid on solar, and use
wlsunset for warm color temperature at night. A grayscale/heavy-tint
mode would be useful both for eye strain at night and as a general
accessibility option — happy to test on real (constrained) hardware
if this moves forward.

Related: #1128 (HDR/color management — different scope, but same
underlying gap from a user's point of view).

[Sempyos]

Long running custom shaders have a tracking issue here: #913