Keep Windows-node capability state truthful across Settings, Gateway declaration, and agent guidance

Problem

A Windows-node capability can appear enabled in Hub Settings while the agent says it cannot use it, or a permitted capability can be undiscoverable to the agent. This creates a trust gap between the UI, Gateway/node declaration, runtime readiness, and chat behavior.

Desired outcome

One authoritative, inspectable capability state drives Settings, diagnostics, node declaration, and agent guidance.

Definition of done

• Report one capability state that includes: Settings toggle, Windows permission, Gateway declaration, pairing/approval, and runtime readiness.
• Surface the state in Command Center and in the context supplied to the agent.
• Provide actionable, unambiguous failure reasons for camera, browser proxy, and system.run.
• Add MCP tools/list and tools/call coverage plus gateway-path proof for each meaningful state transition.

Related

• #850 is the broader tool-containment tracking epic.
• The PCMag report observed camera access enabled in the app while the agent stated that it could not access the camera: https://www.pcmag.com/opinions/microsoft-thinks-openclaw-is-the-future-of-windows-my-testing-says-otherwise

Start by tracing how Settings, Windows permissions, Gateway/node declaration, pairing or approval, and runtime readiness currently expose capability state. Then map the Command Center and agent context paths, and add MCP tools/list and tools/call coverage with gateway-path checks for each meaningful transition; done means one inspectable state and actionable reasons for camera, browser proxy, and system.run failures.