Lay Orchestra out as Kessai: the contract as the root module orchestra, the engine as orchestra_engine

Problem/Motivation

Kessai is laid out the clearest way of the three projects that share this design: its root module, kessai, is the contract every site installs; kessai_engine takes payments on this site; kessai_client takes them through another site instead; kessai_server answers other sites. A site picks its role from the module list, and everything that needs payments to actually happen depends on kessai_engine.

Orchestra has the same layers since #3631451: Rename orchestra_api to orchestra_client_api and orchestra_server_api to orchestra_server, and make the contract part of the engine, with the in-process client in orchestra, as in Personal Data Vault, under other names: the contract is the submodule orchestra_client_api, and the engine is the root module orchestra. So the module every site installs is a submodule, and the root module is one a client-only site must not have.

Proposed resolution

Lay Orchestra out as Kessai:

• orchestra: the contract, from orchestra_client_api (OrchestraClientInterface, the client resolver, wire identities, notice signatures, request limits). Its settings become orchestra.settings. Hidden from the Extend page, as kessai is (and as #3631451: Rename orchestra_api to orchestra_client_api and orchestra_server_api to orchestra_server, and make the contract part of the engine, with the in-process client in orchestra, as in Personal Data Vault already makes orchestra_client_api): it arrives as a dependency of whatever uses it, and a site that installs it alone drives no workflow.
• orchestra_engine: the engine, from today's root module, in Drupal\orchestra_engine, with its config (orchestra_engine.settings, and every engine config entity, such as orchestra_engine.workflow.*). Entity type ids and their tables keep their names.
• orchestra_client and orchestra_server keep their names.
• Every submodule that depends on orchestra:orchestra for the engine depends on orchestra:orchestra_engine, and every kernel test enables both.

Orchestra is pre-beta, so nothing is kept for the old names: no class aliases, no deprecation layer, no update hook.

Remaining tasks

• Implement, one commit per step: move the engine, move the contract into the root, rename the config, update the dependents and tests.
• Write the one-time migration for existing sites, run per site with a backup first: rename the modules in core.extension and their schema versions, rename every engine config object and the dependency lists and third-party settings that name the module, set the provider of the engine's entity types, and re-import the translations under the new projects. Combined with the rename of #3631451: Rename orchestra_api to orchestra_client_api and orchestra_server_api to orchestra_server, and make the contract part of the engine, with the in-process client in orchestra, as in Personal Data Vault, so a site migrates once.
• Follow-ups in the projects that depend on orchestra:orchestra for the engine (yoyaku).
• Update the documentation.

User interface changes

None, beyond the module names in the module list.

API changes

• The engine's classes move from Drupal\orchestra to Drupal\orchestra_engine, and the contract's from Drupal\orchestra_client_api to Drupal\orchestra.
• Service ids follow their module: orchestra.* becomes orchestra_engine.*, orchestra_client_api.* becomes orchestra.*.
• Modules that need the engine depend on orchestra:orchestra_engine.

Data model changes

The engine's config objects are renamed from orchestra.* to orchestra_engine.*, and the contract's from orchestra_client_api.* to orchestra.*. Entity data and tables are unchanged.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)