feat: Support Argo CD Agent's Agent Component in operator #1913
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
What type of PR is this?
/kind enhancement
What does this PR do / why we need it:
The ArgoCD operator is already capable of deploying the argocd-agent's principal components. This PR adds support for deploying the argocd-agent's agent components as well, allowing users to use the ArgoCD operator to deploy both the principal and agent components.
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #NA
How to test changes / Special notes to the reviewer:
I've intentionally avoided disrupting the existing Principal path to minimize regression risk. To keep concerns separated, this PR introduces an agent/ folder that mirrors the structure of the current Principal code. This separation is both safer (fewer unintended cross effects) and more future proof, since the Principal (server) and Agent (client) are likely to diverge further over time. While this does introduce some code duplication, sharing helpers between two components with distinct roles (server vs client) increases the chance that a change for one will accidentally impact the other. That's why I feel like clear boundaries are preferable here.
I also considered creating a principal folder and moving existing files, but that would add a lot inflate this PR. For now, the top level continues to represent the server (Principal), and the new agent folder represents the client, which still reflects a clean server–client structure without unnecessary file moves.