feat: Implement CustomToolsReconciler and generic BaseArtifactReconciler

[Vaishnav88sk]

Fixes #14

Description

This PR introduces the GitOps reconciliation layer for seamlessly syncing CustomTools (and eventually Prompts or Resources) into the Reshapr control plane.

Key Changes

• Updated API Models: Added standard tracking fields (state, serviceId, artifactId, message) to CustomToolsStatus to match existing Reshapr CRD norms.
• ArtifactAttachClient: As the generated OpenAPI attachArtifact endpoint lacked a request body schema definition for multipart/form-data, I hand-wrote an HTTP client mapping the parameters accurately to /v1/artifacts/attach via application/x-www-form-urlencoded.
• BaseArtifactReconciler: Abstracted an extensible workflow for any artifact type, moving findRemoteService from ServiceReconciler into BaseReshaprReconciler for broader reuse across reconciliation loops.
• CustomToolsReconciler: Implemented a concrete orchestrator for CustomTools tracking, serializing .spec.customTools payloads safely via Jackson into JSON before securely calling the attach artifact backend endpoint.

Verification

• Operator successfully intercepts CustomTools instances in the Quarkus dev environment.

[lbroudoux]

That's pretty fast! Have you been able to test it out from end to end? Because I haven't published any documentation yet on how to deploy it, how to configure the Reshapr control plane to allow Kubernetes service account authentication and so on ...

Also, I don't see any new CRD in the PR. You must extract them from /operator/target/kubernetes and put them into /deploy/crdso that Yaml manifests are centralized at the same place.

[Vaishnav88sk]

That's pretty fast! Have you been able to test it out from end to end? Because I haven't published any documentation yet on how to deploy it, how to configure the Reshapr control plane to allow Kubernetes service account authentication and so on ...

Also, I don't see any new CRD in the PR. You must extract them from /operator/target/kubernetes and put them into /deploy/crdso that Yaml manifests are centralized at the same place.

same comment #16 (comment)

[Vaishnav88sk]

Yeah, that makes sense, and I missed! The Operator SDK automatically generated the CRD YAML into the /operator/target/kubernetes directory during the build, which is why it worked perfectly for my local testing. However, since the target/ directory is ignoreed by git, the YAML never got pushed to the PR.

I will manully extract the generated yml and copy it over to /deploy/crd/ to keep everything centralized. I'll push an updated commit shortly!!

[Vaishnav88sk]

I have successfully verified this PR locally in a Minikube cluster environment and made a few necessary fixes to align with the control plane's expectations.

Fixes Applied:

1. Multipart Uploads: Updated ArtifactAttachClient to construct and send a proper multipart/form-data request with a file parameter, as the control plane's attachArtifact endpoint expects a raw file upload rather than URL-encoded form data.
2. Schema Alignment: Updated CustomToolsReconciler to serialize the CustomTools payload so that apiVersion, kind, service, and customTools are at the root level of the JSON document. The backend strictly validates this flat schema rather than the standard nested Kubernetes .spec format.

Steps taken for verification:

1. Built the operator locally and deployed the vaishnav88sk/reshapr-operator:nightly image to Minikube.
2. Created a sample CustomTools resource (ensuring all required schema fields like input were present).
3. Monitored the operator and control plane logs.

Verification Results:
The operator successfully uploaded the artifact, and the resource transitioned to a READY state.

vaishnavsk@vaishnav88:~/reshapr-controllers$ kubectl describe customtools.reshapr.io sample-custom-tools -n reshapr-system
...
Status:
  Artifact Id:  0R4AFEKM1G33M
  Message:      Artifact successfully synchronized
  Service Id:   0R492V3J9G27S
  State:        READY

Here are the operator logs showing the successful intercept and artifact upload to the control plane:

vaishnavsk@vaishnav88:~/reshapr-controllers$ kubectl logs -f deployment/reshapr-operator -n reshapr-system
...
2026-07-27 12:55:09,938 INFO  [io.reshapr.kubernetes.operator.auth.ReshaprApiClientFactory] (ReconcilerExecutor-customtoolsreconciler-129) Creating authenticated API client for instance=reshapr-control-plane-ctrl.reshapr-system, organization=reshapr
2026-07-27 12:55:09,938 INFO  [io.reshapr.kubernetes.operator.auth.ReshaprAuthenticationService] (ReconcilerExecutor-customtoolsreconciler-129) Authenticating to reShapr control plane at 'http://reshapr-control-plane-ctrl.reshapr-system.svc.cluster.local:5555' for organization 'reshapr'
2026-07-27 12:55:10,005 INFO  [io.reshapr.kubernetes.operator.BaseArtifactReconciler] (ReconcilerExecutor-customtoolsreconciler-129) Successfully attached RESHAPR_CUSTOM_TOOLS artifact id=0R4AFEKM1G33M to service id=0R492V3J9G27S for resource 'sample-custom-tools'

Please test it on your side too and let me know your thoughts!

[lbroudoux]

It looks great! Thanks @Vaishnav88sk for the contribution!