Feature: Verified desktop control loop for DMS + niri integration

### Feature Description

Add a verified desktop control loop for DMS when integrated with niri. The feature would combine niri compositor state and DMS/system state so desktop actions can be proposed, executed, observed, verified, and corrected instead of treating request acceptance as final success.

The intended loop is:

`user or DMS proposes action -> expected state is shown or recorded -> DMS/niri operation executes -> DMS re-reads niri IPC plus relevant system state -> result is verified -> mismatch becomes uncertain/failed and can be contested, retried, or revised`

This should not be a global optimizer or an "ethics score." It is a concrete verification workflow for desktop control.

### Use Case

DMS can initiate actions that involve both shell/system state and niri compositor state, such as workspace/window movement or display-related changes. A request may be accepted while the resulting desktop state differs from the expected state because of timing, focus changes, compositor constraints, stale assumptions, user intervention, or state changes from another client.

When that happens, DMS should not silently preserve the old judgment as if it still controls current reality. It should mark the result as `uncertain` or `failed`, keep the historical action record, and allow the user to contest or correct it.

If the user says "this is wrong", DMS should be able to record that as a pending hypothesis instead of treating it as either automatic veto or noise. The UI could then offer likely directions such as fact mismatch, causal mismatch, current state mismatch, user intent mismatch, time/change race, or other, while still allowing open text input.

### Compositor(s)

Niri

### Proposed Solution

For a first proof of concept, implement one narrow end-to-end action chain, for example workspace/window move or a display-related action:

- capture the requested action and expected resulting state
- execute the DMS/niri operation
- re-read relevant niri IPC state and DMS/system reality
- correlate the observation with the action when possible
- mark the result `verified`, `uncertain`, or `failed`
- preserve old judgments as history, but mark them stale when reality changes
- expose a user path to contest, retry, revise, or provide more context

For user contests, DMS could record a pending hypothesis with lightweight classification:

- factual mismatch
- causal mismatch
- current-state mismatch
- user-intent mismatch
- time/race/change mismatch
- other/open input

DMS could then decide whether to check local device state, query niri IPC, inspect logs, or ask the user for clarification.

### Alternatives/Existing Solutions

DMS can directly issue compositor/system requests and update UI optimistically. That is fast, but it can confuse "request accepted" with "desktop reality changed."

Per-feature read-back checks are another option. The proposed control loop is meant to make one complete DMS+niri workflow explicit first, then reuse the pattern only where it proves useful.

Start by identifying the existing DMS/niri operation and the niri IPC and DMS/system-state entry points involved in one narrow action chain. Define the expected state, observation, and correlation data for that action. Done means the result is classified as verified, uncertain, or failed, history is preserved, and the user can contest, retry, or revise it.

Written by the indexing model from the issue text.