Is independent client support intended for remote access? (documentation + compatibility policy)

[SAXEM1997]

Context: I maintain dsh-cherry-bridge, an independent MIT client of @cherrystudio/remote-protocol (a DSH plugin; verified against desktop 2.1.4-2.1.7). I reported #21852 (fixed) and #21951 (open), so this is a question from someone already exercising the protocol, not a drive-by feature request.

Remote access is user-facing - the settings page below is from 2.1.7 - but I cannot find a public description of its intended client surface.

Three questions:

1. Intent. docs/references/api-gateway/remote-agent-access.md scopes v1 to "own Expo / React Native client", while the protocol packages are published on npm. Is an independent client intended to be supported, tolerated, or unsupported? A "first-party only" answer is useful: it tells me how much compatibility work is worth doing.

2. Compatibility. The protocol moved 0.5.0 to 0.6.0 to 0.7.0 in nine days, and the design doc says "Do not promise automatic N-1 compatibility". Is there a policy an independent client can follow - e.g. "wire v1 stays additive; track minors within N days; a breaking change gets a new protocol version"? Even a one-line statement in the docs would remove the guesswork.

3. Docs / community clients. The docs index has no remote/device/pair page. Would a docs page describing the public surface be acceptable - and, if independent clients are tolerated, would a short "community clients" section be acceptable alongside it? I am happy to write the docs PR myself, following your template.

I am not asking for endorsement, support, or a listing of my project specifically. I am asking whether the surface is meant to be public; "no" is a useful answer.

Related: #20693 (desktop-to-desktop controllers; no reply yet), #21728 (enterprise Web client, v2.3.0).