feat(policy): add portable UI controls for MXC sandboxes

[shailendra-nv]

User Story

As an OpenShell operator running Windows sandboxes through MXC, I want a
platform-neutral UI policy so I can explicitly control graphical UI access,
clipboard direction, and synthetic input without embedding Windows-specific
MXC concepts in an OpenShell policy.

Problem Statement

OpenShell cannot currently express MXC's top-level UI controls. The MXC mapper
therefore always emits a restrictive UI object for process containers, and the
same object is incompatible with MXC isolation sessions because the current MXC
implementation rejects any specified top-level UI policy for that backend.

Impact / Why This Matters

Windows sandbox users cannot opt into a graphical application, selectively
allow clipboard reads or writes, or permit input injection through an OpenShell
policy. The only workaround is to bypass or modify the mapper, which loses the
portable OpenShell policy boundary and is unsuitable for managed sandboxes.
The mapper's unconditional restrictive UI output also prevents otherwise valid
isolation-session configurations from reaching current MXC.

Proposed Design

Add an optional, typed, static ui section to the version 1 OpenShell policy:

ui:
  allow_graphical_ui: false
  clipboard: none
  allow_input_injection: false

The field names describe portable capabilities rather than Windows APIs.
clipboard accepts none, read, write, or all. Missing fields default
to deny. Existing policies remain unchanged because absence is distinct from
an explicitly present UI section.

On Windows MXC process containers, map the three capabilities to MXC's
top-level ui.disable, ui.clipboard, and ui.injection. Preserve the current
explicit restrictive MXC output when the OpenShell section is absent. On MXC
isolation sessions, omit UI when it is absent and reject an explicit UI section
before invoking wxc-exec, because the current MXC backend rejects any present
UI policy. Do not expose MXC's Windows-specific desktop, system-settings, IME,
or isolation controls.

The section is immutable after sandbox creation and participates in static
policy comparison and hashing. Non-Windows compute paths retain their current
behavior and do not implement UI allowances; the new capabilities remain
default-deny there.

Alternatives Considered

• Expose MXC's JSON shape directly. Rejected because it would leak
  backend-specific and Windows-specific concepts into an OS-agnostic policy.
• Add generic host-device or desktop-system-control fields now. Rejected
  because the semantics are not portable across operating systems.
• Keep unconditional MXC UI output for isolation sessions. Rejected because
  current MXC explicitly rejects any specified top-level UI object.
• Silently discard explicit UI policy on an unsupported MXC backend. Rejected
  because requested security policy must not be reported as enforced when it
  is not representable.

Agent Investigation

The design was checked against Microsoft MXC main and its upcoming
0.9.0-dev schema. The dev schema defines the portable top-level ui controls
used above, while Windows-only controls remain nested under
processContainer.ui. OpenShell's current mapper, protobuf conversions, static
policy checks, hash behavior, documentation, and Windows build lanes were
inventoried before implementation.

Acceptance Criteria

• The version 1 protobuf and YAML policy surface includes the typed,
  optional, platform-neutral UI section and preserves absent versus
  explicitly empty presence.
• Missing UI values default to deny, and non-Windows runtime behavior is
  unchanged.
• UI policy is static, hash-significant, deterministic, and round-trips
  through protobuf/YAML conversions.
• MXC process containers map every UI capability exactly and preserve the
  legacy deny output when the OpenShell section is absent.
• MXC isolation sessions omit absent UI and reject explicit UI before
  invoking MXC.
• Mapper, schema, conversion, hashing, and platform-boundary tests cover
  the new behavior.
• Relevant architecture, user, crate, and agent-skill documentation is
  updated.
• Linux/non-Windows CI, Windows x64, and native Windows ARM64 validation
  pass.
• Real-MXC tests pass first against the installed baseline and then against
  the latest MXC revision, with the system MXC left on the latest tested
  build.