[feat] Expose a read-only capability registry for native vs compatibility paths

Summary

Please expose a read-only capability registry in Desktop Commander so clients can distinguish what is natively available, what is available only through structured/text compatibility paths, and what is not exposed.

A good shape would be a dedicated tool such as get_capabilities, generated from the live tool catalog + runtime/provider capability flags rather than from static prose.

Why this is needed

On a verified Windows subject running Desktop Commander 0.2.50:

• get_prompts loads package-owned dist/data/onboarding-prompts.json;
• the current onboarding/tool description enumerates a fixed set of onboarding options;
• there is no verified user-level capability-registry hook that can inform every invoker dynamically.

That creates two recurring failure modes:

1. a compatibility workflow is incorrectly described as impossible because there is no first-class native file parameter;
2. a textual/Base64 carrier is incorrectly described as if it were a native/private binary file channel.

Suggested registry fields

For each capability:

• direction: downstream / upstream / provider-control;
• status: available / conditional / unavailable / provider-pending;
• transport class: native / structured-reader / textual-carrier / local-generation;
• confidentiality properties;
• known size/scale limits;
• evidence source: live schema, runtime capability negotiation, provider feature flag, or local extension.

At minimum, the core registry should expose:

• registered filesystem/process/read/write tool capabilities;
• structured format support from the current schemas;
• whether native host-file ingress exists;
• whether native device-file -> host/chat file-object upload exists;
• device capability flags such as artifact receiver support when implemented;
• current app/client versions relevant to capability negotiation.

Optional local extension namespace

A provider-supported read-only extension mechanism would be useful for locally qualified composite workflows. Core/provider facts and user/local extensions should remain separate namespaces.

Any extension should declare at least:

• transport_class;
• confidential;
• scope;
• evidence.

This prevents local workflows from being misrepresented as native RDC capabilities.

Factual motivation

Qualification work on the current tool contracts showed that:

• device-side reconstruction/build can materialize binary artifacts without native host-file transfer;
• exact host/ChatGPT -> Windows bytes can be delivered through bounded text/Base64 carriers with independent size/SHA verification;
• the reverse Windows -> ChatGPT exact-byte mechanism is also possible through a text/Base64 carrier at proof scale;
• neither direction should be labeled a native/private binary file channel.

First-class native host-file ingress remains a separate feature request tracked in #719.

Onboarding

Please add an onboarding option such as “Understand what Desktop Commander can do on this device” that invokes the capability registry dynamically rather than embedding static capability claims in prompt text.

Security

The registry must be read-only and must not expose:

• credentials or bearer tokens;
• signed URLs;
• private object/storage keys;
• secret material.

Text/Base64 carrier paths should never be labeled confidential.

This request is about capability disclosure and correct classification, not about changing current security boundaries or silently enabling new permissions.