Ask the platform what colour the screen actually is

FR-DSP-8's acquisition half. `dr_plat::display` surveys the session's
displays and reduces each one's profile to an output space the pipeline
can encode into, stating the mechanism per display server as
FR-PLAT-LIN-2 requires:

  - X11 reads the `_ICC_PROFILE` / `_ICC_PROFILE_<n>` root-window
    properties, enumerating and numbering the outputs through RandR,
    which also yields the rectangles a window move is measured against.
  - Wayland binds `wp_color_manager_v1` and asks each `wl_output` for
    its image description, accepting either an ICC profile on a file
    descriptor or primaries stated as chromaticities.
  - Where neither answers, sRGB is assumed and the reason travels with
    it as data rather than into a log, so the About page can say which
    path the session is on.

A display profile is a measurement of one panel and is none of the four
spaces the pipeline knows. Rather than grow an ICC engine, the profile
is reduced to D50-adapted colorants and matched against the four; a
match that is merely nearest is marked as such and shown as such.

Verified on this machine: mutter 50 advertises the colour-management
global and reports eDP-1 as sRGB, and the same session forced onto X11
enumerates the output through RandR and correctly finds no atom.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

platform/dr-plat/Cargo.toml

@@ -12,6 +12,12 @@ log.workspace = true
 
 [target.'cfg(all(unix, not(target_os = "android")))'.dependencies]
 keyring.workspace = true
+# The two display servers FR-PLAT-LIN-2 names, each asked for the profile it
+# knows how to state (FR-DSP-8, `display.rs`). Both are already in the tree
+# via winit, so this adds compilation of nothing that was not already built.
+x11rb.workspace = true
+wayland-client.workspace = true
+wayland-protocols.workspace = true
 
 [target.'cfg(target_os = "android")'.dependencies]
 android-native-keyring-store.workspace = true