Enhance documentation for k8sattributes processor

[srclosson]

Added details about multi-tier deployments and workarounds for k8sattributes processor.

Brief description of Pull Request

Pull Request Details

Issue(s) fixed by this Pull Request

Notes to the Reviewer

PR Checklist

• Documentation added
• Tests updated
• Config converters updated

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

💻 Deploy preview available (Enhance documentation for k8sattributes processor):

• https://deploy-preview-alloy-5341-zb444pucvq-vp.a.run.app/docs/alloy/latest/

[clayton-cornell]

Some rewrite suggestions - some minor style fixes, and then some rewrites to use active voice where possible and write for positive action vs negative (example in the note... switched it around)

[clayton-cornell]

Suggested change

	**Multi-tier deployments:** When using a two-tier architecture where DaemonSet {{< param "PRODUCT_NAME" >}} instances forward telemetry to a centralized Deployment {{< param "PRODUCT_NAME" >}}, the k8sattributes processor in the Deployment cannot determine which pod originally sent the telemetry. This happens because:
	**Multi-tier deployments:** If you use a two-tier architecture where {{< param "PRODUCT_NAME" >}} instances deployed as a DaemonSet forward telemetry to a centralized {{< param "PRODUCT_NAME" >}} Deployment, the k8sattributes processor in the Deployment can't determine which Pod originally sent the telemetry. This happens for the following reasons:

[clayton-cornell]

Suggested change

	1. The k8sattributes processor identifies pods using the connection source IP, `k8s.pod.ip`, or `k8s.pod.uid` attributes
	2. When telemetry is forwarded through a DaemonSet, the Deployment sees the DaemonSet pod's IP as the source, not the original application pod's IP
	3. If the telemetry doesn't already contain `k8s.pod.ip` or `k8s.pod.uid` attributes, the Deployment cannot look up the pod's Kubernetes metadata
	1. The k8sattributes processor relies on the connection source IP, `k8s.pod.ip`, or `k8s.pod.uid` attributes to identify Pods.
	1. When telemetry passes through a DaemonSet, the Deployment sees the DaemonSet Pod's IP instead of the original application Pod's IP.
	1. The Deployment can't retrieve metadata for the original Pod unless the telemetry contains `k8s.pod.ip` or `k8s.pod.uid` attributes.

[clayton-cornell]

Suggested change

	**Workaround:** Configure the DaemonSet {{< param "PRODUCT_NAME" >}} with `passthrough = true`. This ensures the DaemonSet adds Kubernetes attributes (like `k8s.namespace.name`) before forwarding, so the Deployment receives telemetry with metadata already attached. The Deployment's k8sattributes processor will then pass through the existing attributes without modification.
	To address this, configure {{< param "PRODUCT_NAME" >}} that runs as a DaemonSet with `passthrough = true`. This ensures the DaemonSet adds Kubernetes attributes, like `k8s.namespace.name`, before forwarding, so the Deployment receives telemetry with metadata already attached. The Deployment's k8sattributes processor then passes through the attributes without modification.

[clayton-cornell]

Suggested change

	**Note:** If your {{< param "PRODUCT_NAME" >}} receives telemetry directly from application pods (not forwarded from another {{< param "PRODUCT_NAME" >}}), keep `passthrough = false` (the default).
	{{< admonition type="note" >}}
	You only need to set `passthrough = true` in multi-tier deployments where another {{< param "PRODUCT_NAME" >}} instance forwards the telemetry.
	{{< /admonition >}}