feat(runtime): add reset executable endpoint

[johnBgood]

Description

Adds a manual reset capability for inbound connector executables:

• POST /inbound-instances/{type}/executables/{executableId}/reset
• Deactivates the current executable and re-activates it with a fresh instance while reusing the same context
• Supports Activated and Cancelled states
• Returns the updated ActiveInboundConnectorResponse after reset
• Forwards to the correct runtime instance in multi-instance deployments

Related issues

closes #6737

Checklist

• Backport labels are added if these code changes should be backported. No backport label is added to the latest
  release, as this branch will be rebased onto main before the next release. Example backport labels:
  • backport stable/8.8: for changes that should be included in the next 8.8.x release.
  • or backport release-8.8.7: for changes that should be included in the specific release 8.8.7, and this
    release has already been created. The release branch will be merged back into stable/8.8 later, so the change
    will be included in future 8.8.x releases as well.
• Tests/Integration tests for the changes have been added if applicable.

[Copilot]

Pull request overview

Adds a runtime-management capability to manually reset an inbound connector executable via a new REST endpoint, leveraging the existing inbound executable registry and batch processing infrastructure.

Changes:

• Added POST /inbound-instances/{type}/executables/{executableId}/reset endpoint that triggers an executable reset and returns an ActiveInboundConnectorResponse.
• Introduced InboundExecutableRegistry.reset(ExecutableId) and implemented it in InboundExecutableRegistryImpl.
• Added BatchExecutableProcessor.restartFromContext(RegisteredExecutable) helper to restart using an existing executable’s context.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
connector-runtime/connector-runtime-spring/src/main/java/io/camunda/connector/runtime/instances/service/InboundInstancesService.java	Adds resetExecutable(...) service method used by the REST endpoint.
connector-runtime/connector-runtime-spring/src/main/java/io/camunda/connector/runtime/inbound/executable/InboundExecutableRegistryImpl.java	Implements registry-level reset by restarting an executable from its current state/context.
connector-runtime/connector-runtime-spring/src/main/java/io/camunda/connector/runtime/inbound/executable/InboundExecutableRegistry.java	Extends the public registry interface with a reset(ExecutableId) API.
connector-runtime/connector-runtime-spring/src/main/java/io/camunda/connector/runtime/inbound/executable/BatchExecutableProcessor.java	Adds restart-from-context convenience method used by reset.
connector-runtime/connector-runtime-spring/src/main/java/io/camunda/connector/runtime/inbound/controller/InboundInstancesRestController.java	Exposes the new reset endpoint under /inbound-instances.

[mathias-vandaele]

is'nt it the opposite ? 🤔

[mathias-vandaele]

We should validate the state before really doing it, there could be a race condition where this has been deactivated because a new version of the process has came, and we would reactivate it.

It could be alive without any corresponding process definition

[mathias-vandaele]

I think the bot comment is irrelevant, the problem here is that we are missing a unified concurrency model and therefore we have to do such things, this class needs to be refactored properly at some point 😅