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!!