Take out the two upgrade paths: a pre-1.0 alpha is reinstalled, not upgraded

Orchestra is pre-1.0. It breaks what it needs to break between alphas, and reinstalling is the supported answer. Two hooks say otherwise:

• orchestra_server_api_update_11001() in modules/orchestra_server_api/orchestra_server_api.install, which installs the orchestra_identity_schemes field storage on the consumer entity;
• orchestra_client_post_update_remote_entities() in modules/orchestra_client/orchestra_client.post_update.php, which moves a single remote setting into a remote Orchestra entity and deletes the settings object.

A site running drush updb is told this module has an upgrade path, gets those two run, and has no reason to think the rest of an alpha cycle of schema changes was handled the same way. It was not: entity types have been renamed, base fields added and columns retyped across these alphas with no hook behind any of them, which is the project working as intended. Two hooks in the tree make that look like an oversight rather than the rule.

update_11001 is also a second home for something hook_install already owns. The install hook installs four consumer field definitions from _orchestra_server_api_consumer_fields(), a list named once on purpose so installing and uninstalling cannot come to disagree about what this module put there. The update hook installs the fourth of them again, from its own copy of the call.

Proposed resolution

• Delete orchestra_server_api_update_11001().
• Delete orchestra_client.post_update.php.
• Add a guard over the shipped files: this project declares no hook_update_N and no hook_post_update_NAME, so the next one fails a test rather than arriving quietly.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)