Issue #3623406: Run a subprocess child on a remote Orchestra, and give both subprocess nodes one answer for a child's ending

First piece of #3623406: a site can call a child process on another Orchestra, over a connection it names.

What is on the branch

Connections are configuration. orchestra_client.settings held one base_url / client_id / secret_key, so a site could reach exactly one Orchestra. That becomes the orchestra_remote config entity, one per engine this site calls, each with its own access token in state and its credential still in a Key. RemoteTokenProvider and RemoteOrchestraClient take the connection they speak to instead of reading the site's settings, and RemoteClientFactory builds one client per connection.

Both halves answer at once. The site-wide binding still exists for code that names no connection, but it is now a lazy delegator resolving the default connection per call, so building a service that holds the contract no longer depends on this site having an outgoing connection at all. That is what lets one site answer the API and call another Orchestra, which the mutual case in the issue needs.

The node. The new orchestra_remote_process submodule ships a remote_subprocess task: it starts the child over the connection the node names, records the connection and the child's id there as a pair, and carries variables both ways through the same input/output maps the local subprocess uses. A child that has already finished when the start answers (a remote running synchronously drains it inside the start call) advances the parent in that same request. One still running parks the parent, and the cron poll resumes it with the mapped output, routes a failed or canceled child through the node's state variable, and leaves the parent parked when the node routes nothing.

A post_update carries the old setting into a default connection and forgets the site-wide cached token.

Verification

• orchestra_client kernel suite: 37 tests, 107 assertions, green (the 4 deprecations are the key module's annotated entity type).
• orchestra_remote_process kernel suite: 5 tests, 78 assertions, green. It drives the whole path against a stubbed remote: the synchronous child, the parked child resumed by the poll, both failed-child shapes, and one start per token on a retried advance.
• phpcs Drupal and DrupalPractice: clean.

Deliberately not here yet

• The signed event notices. The poll is the only way a parent hears about its child today. Worth knowing for that piece: the instance payload carries no uuid, so a notice has nothing stable to correlate on until one is added.
• A cancel operation on the client contract, so a parent timeout can reach the child instead of orphaning it.
• The initiator across the hop (the account login rather than a uid), and the permission that lets a consumer attribute a run.
• Documentation and the French catalogs.

Draft until those land or are split out.