Expose WorkflowExecutions and WorkflowDefinitions

[lisajulia]

The Node plugin (@cap-js/n8n) exposes the n8n public REST API (<n8n-base-url>/api/v1/...) as two CDS entities that consuming applications can query and act on programmatically. The Java plugin
currently has no equivalent - it is trigger-only.

What the Node plugin exposes

WorkflowExecutions

• GET /api/v1/executions - list with optional workflowId, status, limit filters
• GET /api/v1/executions/{id}?includeData=true - read single execution with payload
• DELETE /api/v1/executions/{id} - delete execution
• POST /api/v1/executions/{id}/retry - retry with optional loadWorkflow flag
• POST /api/v1/executions/{id}/stop - stop a running execution

WorkflowDefinitions

• GET /api/v1/workflows - list with optional active, name, limit filters
• GET /api/v1/workflows/{id} - read single workflow
• POST /api/v1/workflows - create workflow
• PUT /api/v1/workflows/{id} - update (partial UPDATE is bridged by fetching missing required fields first)
• DELETE /api/v1/workflows/{id} - delete workflow
• POST /api/v1/workflows/{id}/publish - publish
• POST /api/v1/workflows/{id}/unpublish - unpublish
• POST /api/v1/workflows/{id}/archive - archive

Possible implementation here

Add a new N8nService CDS service definition exposing the same two entities and actions.
Implement a Spring @Component handler that maps CDS CRUD events and actions to REST calls
against /api/v1/....

The existing n8n.base-url, n8n.api-key, and BTP destination wiring in
N8nWebhookService can be reused for the REST client - the /webhook prefix is already
stripped in the base URL; the API calls go to the same host at /api/v1/.

Console mode

In console mode, the Node plugin stores WorkflowExecutions and WorkflowDefinitions in an in-memory SQLite db.
For the Java plugin, this should be done with an in-memory H2 db.