[Feature Request] Add versioned device capability contracts and protocol preflight

[SchrodingersCattt]

Problem

Protocol actions expose schemas, but there is no uniform, versioned capability contract connecting action parameters to device limits, telemetry, artifacts, or safety state.

Concrete code evidence

• unilabos/compile/heatchill_protocol.py:93-114 hard-codes temperature/time/speed limits inside the compiler.
• unilabos/devices/xrd_d7mate/xrd_d7mate.py:340-364 hard-codes scan limits directly in the driver, including start_theta >= 5.0.
• unilabos/compile/evacuateandrefill_protocol.py:247-267, 378-399 selects timing and repetition behavior internally rather than querying a capability contract.
• Existing workflow input preflight in [Workflow] Phase 02H：实现 Task input preflight 与 Handle binding #301 validates task values and bindings, but does not provide a common device capability/preflight layer.

Design gap

The same physical constraint can be encoded in a compiler, driver, YAML file, or mock device with no versioned source of truth. Callers cannot reliably know whether a result means command accepted, device executed, telemetry observed, or raw data saved.

Proposed capability contract

A device instance/adapter should declare, in a versioned machine-readable form:

• operations and parameter schemas;
• supported units and conversions;
• numeric/discrete ranges;
• supported time scales and modes;
• telemetry fields and freshness;
• raw artifact capabilities;
• safety interlocks and human-confirmation requirements;
• simulation-only versus physically verified capabilities.

Acceptance criteria

• Protocol preflight checks the selected device instance and method before producing actions.
• Limits move out of scattered compiler constants into the capability contract.
• Capability version is captured in workflow/run snapshots.
• Diagnostics distinguish unsupported, unavailable, unsafe, and ambiguous states.
• The implementation extends [Workflow] Phase 02H：实现 Task input preflight 与 Handle binding #301 rather than introducing a second disconnected validation path.

[SchrodingersCattt]

Cross-reference from Core #234, #235, and #236: this OS issue remains the authority for capability/preflight behavior. Core tracks where vendor/profile schemas are owned and loaded; it does not define a second capability contract.