[EKS] [request]: Argo CD capability — support Applications/ApplicationSets outside the capability namespace (docs currently contradict actual behavior)

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

Support upstream Argo CD's "Applications in any namespace" / "ApplicationSet in any namespace" in the EKS Capability for Argo CD, so that `AppProject.spec.sourceNamespaces` takes effect for namespaces other than the one configured at capability creation time.

Separately and more urgently: the user guide currently documents this as working when it does not. Details below.

**Which service(s) is this request for?**

EKS — EKS Capabilities (Argo CD)

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

We run the Argo CD capability with `configuration.argoCd.namespace: argocd`. We want tenant teams to own `Application`/`ApplicationSet` CRs in their own namespaces rather than all writing into the shared `argocd` namespace — the standard multi-tenancy pattern upstream, and the reason apps-in-any-namespace exists.

There are two distinct problems.

*1. The documentation contradicts itself.* Three pages disagree:

* [`argocd-permissions.html`](https://docs.aws.amazon.com/eks/latest/userguide/argocd-permissions.html) states the capability "only supports a single namespace for Applications and ApplicationSets — the namespace you specified when creating the capability," and notes this differs from OSS Argo CD.
* [`argocd-projects.html`](https://docs.aws.amazon.com/eks/latest/userguide/argocd-projects.html) states the opposite: "If you need to create Applications or ApplicationSets in additional namespaces, modify the sourceNamespaces field to add those namespaces," with a worked example using `team-a-apps` / `team-b-apps`, and a second example listing `argocd`, `team-a-dev`, `team-a-prod`.
* [`argocd-comparison.html`](https://docs.aws.amazon.com/eks/latest/userguide/argocd-comparison.html) hedges — single namespace for the CRs, with `sourceNamespaces` "typically" set to the capability namespace.

We followed `argocd-projects.html` and built against behavior that does not exist.

*2. The failure is silent.* Adding extra namespaces to `sourceNamespaces` is accepted by the API server and the AppProject reports no error. `Application` CRs created in those namespaces are simply never reconciled — no sync status, no condition, no event, nothing in the Argo CD UI, nothing in capability health. There is no signal distinguishing "unsupported" from "misconfigured."

Impact: we cannot delegate Application ownership to teams without granting write access to the shared `argocd` namespace, where cluster secrets and repository credentials live. For regulated environments this is a least-privilege regression versus self-managed Argo CD.

**Are you currently working around this issue?**

Not on the capability — we run self-managed Argo CD, where `--application-namespaces` on the controller and server gives us what we need.

**Additional context**

There are two asks here, and they are separable — the docs fix is independent of the feature and much cheaper:

1. Short term: correct `argocd-projects.html` to match `argocd-permissions.html`, and ideally reject or warn on `sourceNamespaces` entries outside the capability namespace rather than silently ignoring them. A validation error at apply time would have saved the entire investigation.
2. Longer term: support the feature itself.

**Attachments**

Start by comparing docs/userguide/argocd-permissions.html, argocd-projects.html, and argocd-comparison.html, then verify the documented behavior against the EKS Argo CD capability configuration described in the issue. The documentation portion is done when the pages agree and accurately describe sourceNamespaces; the broader feature requires confirming how Applications and ApplicationSets outside the capability namespace are handled and defining an observable validation or reconciliation outcome.

Written by the indexing model from the issue text.