Add missing endpoints and separate generated code

[IgorChvyrov-sm]

Changes:

1. Generated Missing API endpoints:

   1. admin_resource_api:
      1. /admin/cache/clear/{taskDefName
      2. /admin/redisUsage
      3. /admin/sweep/requeue/{workflowId}
      4. /admin/consistency/verifyAndRepair/{workflowId}
      5. /admin/task/{tasktype}
   2. application_resource_api:
      1. POST /applications/{applicationId}/accessKeys/{keyId}/status
   3. environment_resource_api:
      1. PUT /environment/{key}
      2. DELETE /environment/{key}
      3. DELETE /environment/{name}/tags
      4. GET /environment/{key}
      5. GET /environment
      6. GET /environment/{name}/tags
      7. PUT /environment/{name}/tags
   4. event_execution_resource_api:
      1. GET /event/execution
      2. GET /event/execution/{event}
   5. event_message_resource_api:
      1. GET /event/message
      2. GET /event/message/{event}
   6. event_resource_api:
      1. DELETE /event/{name}/tags
      2. GET /event/handler/{name}
      3. PUT /event/queue/config/{queueType}/{queueName}
      4. PUT /event/{name}/tags
      5. DELETE /event/name
      6. GET /event/handler/
      7. GET /event/queue/connectivity
   7. group_resource_api:
      1. POST /groups/{groupId}/users
      2. DELETE /groups/{groupId}/users
   8. incomming_webhook_resource_api:
      1. GET /webhook/{id}
      2. POST /webhook/{id}
   9. integration_resource_api:
      1. GET /integrations/
      2. POST /integrations/eventStats/{type}
      3. POST /integrations/
   10. limits_resource_api:
       1. GET /limits
   11. metrics_resource_api:
       1. GET /metrics/task/{taskName}
   12. metrics_token_resource_api:
       1. GET /metrics/token
   13. prompt_resource_api:
       1. POST /prompts/
   14. queue_admin_resource_api:
       1. GET /queue/
       2. GET /queue/size
   15. scheduler_bulk_resource_api:
       1. PUT /scheduler/bulk/pause
       2. PUT /scheduler/bulk/resume
   16. scheduler_resource_api:
       1. DELETE /scheduler/schedules/{name}/tags
   17. secret_resource_api:
       1. GET /secrets/clearLocalCache
       2. GET /secrets/clearRedisCache
   18. user_resource_api:
       1. GET /users/{userId}/checkPermissions
   19. version_resource_api:
       1. GET /version
   20. webhook_resource_api
   21. workflow_bulk_resource_api:
       1. POST /workflow/bulk/delete

2. Created Resource API adapters

3. Created Models adapters

4. Introduced proxy package to achieve backward compatibility

5. Added integration provider functionality to OrkesIntegrationClient

6. Added integration tests for Orkes clients

[nthmost-orkes]

Just for posterity (and to help myself since I'm new!), I'm going to write a few notes here.

I can see this is a PR consisting overwhelmingly of mechanical refactoring, with structural improvement to support the SDK Roadmap:

https://docs.google.com/document/d/12fdAkJfBsBhLM7jS87uGKnFyDl2gCro6dTIgcWxL-BY/edit?tab=t.0#heading=h.3g6oli2c87ry

The adapter pattern creates 3 files for every API (codegen + adapter + proxy).

Some insights generated by Claude Code:

✏️ Real Changes (<10% of files and LOC)

1. Import path updates in ~50 example files:
   - conductor.client.ai.configuration → conductor.shared.ai.enums
   - conductor.client.http.models → conductor.client.adapters.models
2. New documentation:
   - CLIENT_REGENERATION_GUIDE.md (315 lines)
3. Real new functionality:
   - Integration API support (a handful of actual implementation files)
   - Some adapter methods like TaskAdapter.to_task_result()

💡 Stats:

• ~695 files (80%) are boilerplate: Generated code + stub adapters + proxy re-exports
• ~150 files (17%) are import updates: Examples and tests updating import paths
• ~30 files (3%) are actual new code: Integration features and documentation

I'm can approve this PR on the basis that e2e tests exist (even if they're incomplete), so if these underlying structural changes don't break anything, it's probably fine. 👍🏼

(And very minor thing that need not hold up the PR: from future imports should probably be removed going forward.)

HOWEVER I have a concern about potential overengineering that I'd like to clear up @IgorChvyrov-sm before approving this.

rethinking this after seeing #326 -- concerns about architecture and possible impacts to SDK-user (developer) experience