[0.3.0] Color-manage the main canvas and add proof and separation preview

[mberrys]

Part of #155.

Problem

The main canvas is an unmanaged RGB surface. What the operator looks at while making colour decisions is not colour-managed to their display and does not show separations.

Current state:

• PDFDrawWidget::paintEvent (pdfdrawwidget.cpp:807-858) paints through QPainter or a Blend2D framebuffer in QImage::Format_ARGB32_Premultiplied. Both are device RGB.
• A full LittleCMS integration exists — pdfcms.cpp implements PDFLittleCMS with fillRGBBufferFromDeviceCMYK, XYZ handling, and rendering intents — but its output is RGB for display, and no monitor profile is applied to the canvas surface.
• Separation-aware compositing lives in pdftransparencyrenderer.cpp, reachable through the Output Preview and Soft Proofing plugins, not the main canvas.
• R-002 in docs/V1_RELEASE_READINESS.md accepts this for V1 with a disclosure: the report panel tells the operator that "page view does not simulate overprint" and to use Output Preview. The disclosure is honest. It is also an admission that the primary working surface is not trustworthy for colour.

Why this is the largest remaining fidelity gap: a print operator's core loop is look at the artwork and judge it. Acrobat's Output Preview and InDesign's separation preview put ink coverage, separation isolation, and proof simulation on the working surface, not behind a modal tool. Loupe's positioning — "precise: exact about... color" — is measured against that.

This issue is about the display path: monitor profile, proof simulation, separation preview, and ink coverage on the canvas. It is deliberately not the overprint-compositing work in #49 / #52 / #14, which owns the compositing model itself. The two meet at the renderer, and #49's outcome determines whether the canvas can show overprint correctly — but a colour-managed canvas with separation preview is a distinct, separately valuable deliverable.

Scope

1. Apply the display profile to the canvas: monitor ICC profile from the OS (per display, following the window), with an operator override, using the CMS that already exists.
2. Proof setup on the canvas: choose an output intent / destination profile and a rendering intent, with black-point compensation, and render the page under it — the equivalent of soft proofing, in the main view rather than a separate plugin surface.
3. Separation preview on the canvas: show/hide individual process and spot inks, isolate a separation, and view total ink coverage as an overlay with a configurable threshold.
4. A visible, always-correct indicator of the current view mode — managed or unmanaged, proofing or not, which separations are hidden. The operator must never be unsure whether what they are seeing is a proof. Hidden separations in particular are a trap: an isolated view that silently persists is worse than no separation preview.
5. Reconcile with the existing Output Preview and Soft Proofing plugins — either absorb them into the canvas (consistent with ADR-005 surface pruning) or define which is authoritative. Two colour paths with different answers is the "surface divergence" risk the platform doc names.
6. Performance: colour-managed and separation-preview rendering must respect the [0.8.0] Interaction quality and direct-manipulation foundation #139 latency budgets or degrade explicitly and visibly, never silently.

Acceptance criteria

• Canvas rendering matches the Output Preview renderer for the same page and settings, within a documented tolerance, on a differential corpus.
• Changing the display profile or moving the window to a display with a different profile updates the canvas.
• Total-ink-coverage overlay agrees with the TAC measurement produced for Add total-ink-coverage threshold findings using the existing output-preview renderer #13 — the same number, from the same computation, in both places.
• Separation isolation state is visible at all times and does not persist silently across document switches.
• Frame timings under colour-managed and separation-preview modes are captured in the [0.8.0] Automate interaction-performance regression traces #146 traces; any mode that cannot meet budget is labelled in the UI rather than quietly slow.
• The R-002 disclosure text is revised to match whatever remains true after this work.

Test strategy

• Differential rendering against the corpus in Build a differential prepress-rendering corpus for color, transparency, spot inks, and overprint #87, comparing the canvas path to the transparency renderer.
• Fixtures with named spots, rich black, and high-TAC regions; assert overlay and isolation behaviour.
• Round-trip test: proof settings persist per document/session and are restored.
• Performance traces under the [0.8.0] Automate interaction-performance regression traces #146 harness for managed, proofing, and separation-preview modes.

Dependencies

• [0.8.0] Overprint-correct rendering in standard and advanced renderers #49 / [0.2.0] Implement overprint-aware rendering and detect unsafe/white overprint #52 / Implement overprint-aware rendering and detect unsafe/white overprint (tracker #14) — Done #14 — overprint compositing; determines whether the canvas can show overprint correctly. Coordinate, do not absorb.
• Validate output-intent and ICC-profile presence, identity, and color-space consistency #12 / Implement ICC-managed RGB-to-CMYK conversion with proofing and revalidation #20 — output intent and ICC conversion; proof setup should default from the document's output intent when present.
• Add total-ink-coverage threshold findings using the existing output-preview renderer #13 — TAC findings; shares the computation with the coverage overlay.
• Build a differential prepress-rendering corpus for color, transparency, spot inks, and overprint #87 — differential prepress rendering corpus; this is the corpus this work is validated against.
• [P1] Native PDFium for desktop viewer via Tauri/Rust FFI #118 (closed) — native rendering decision, referenced by [0.8.0] Overprint-correct rendering in standard and advanced renderers #49 as a blocker.