fix(site/docs): grammar fixes and k8s sidecar ref for concepts section (#1306)

Author: tiswanso

site/docs/concepts/architecture/control-plane.md

@@ -90,7 +90,7 @@ The AI Gateway Controller manages AI-specific components and configurations:
 #### ExtProc Management
 
 - Creates and updates ExtProc Secrets with processing rules as well as credentials
-- Inserts the AI Gateway ExtProc as a sidecar container in the Envoy Proxy Pod via the [Kubernetes Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/). The container mounts the ExtProc config secret and communicates with the Envoy Proxy to process AI traffic.
+- Inserts the AI Gateway ExtProc as a [sidecar container](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) in the Envoy Proxy Pod via the [Kubernetes Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/). The container mounts the ExtProc config secret and communicates with the Envoy Proxy to process AI traffic.
 
 #### Resource Management
 
@@ -122,8 +122,8 @@ The AI Gateway Controller manages AI-specific components and configurations:
 - Inserting the ExtProc as a sidecar container brings the following benefits:
   - Performance: Running the ExtProc as a sidecar within the same Pod as Envoy Proxy reduces network latency and overhead, leading to faster processing of AI traffic. Notably, the communication between Envoy Proxy and the ExtProc happens over a local Unix Domain Socket (UDS), not over the network.
   - Simplified Deployment: Managing the ExtProc as part of the Envoy Proxy Pod simplifies deployment and scaling, as both components can be managed together.
-  - Session Affinity: Running as a sidecar natural ensures the session affinity between Envoy Proxy and the ExtProc which is crucial for implementing provider fallbacks. As we explain in [Data Plane and Traffic Flow], we have two phases in the request processing:
-    Router-level and Upstream-level processing to handle provider fallbacks. Since Envoy does not support session affinity for External Processor access as of writing, without the session affinity, the Upstream-level ext proc might end up talking to a different ext proc instance which does not have the context of the router level processing, mainly the original request body and headers.
+  - Session Affinity: Running as a sidecar naturally ensures the session affinity between Envoy Proxy and the ExtProc which is crucial for implementing provider fallbacks. As we explain in [Data Plane and Traffic Flow], we have two phases in the request processing:
+    Router-level and Upstream-level processing to handle provider fallbacks. Since Envoy does not support session affinity for External Processor access as of this writing, without the session affinity, the Upstream-level ExtProc might end up talking to a different ExtProc instance which does not have the context of the router level processing (mainly the original request body and headers).
 
 ## Next Steps
 

site/docs/concepts/architecture/data-plane.md

@@ -121,7 +121,7 @@ The data plane processes requests through several key steps:
 - Why the External Processor is separated into two phases (Router-level and Upstream-level):
   - In Envoy, retry/fallback happens after the router filter at the upstream level. For example, when the upstream server returns 5xx, Envoy does not invoke the router level filter again.
     Instead, it invokes only the upstream level filters. In our case, retry/fallback will make the requests to totally different AI providers. For example, on the first try, it goes to OpenAI, and on the second try, it goes to AWS Bedrock.
-    In this case, we need to do different request transformations and upstream authorizations. So, these logic needs to be in the upstream level filter.
+    In this case, we need to do different request transformations and upstream authorizations. So, this logic needs to be in the upstream level filter.
 - Why the External Processor?
   - The External Processor is the most powerful battle-tested and production-ready extension point in Envoy. It allows us to implement complex logic without modifying Envoy's core codebase.
   - [Dynamic Modules](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/dynamic_modules) could be a future alternative as it offers better performance as well as less complexity in the overall architecture. The work is tracked in [envoyproxy/ai-gateway#90](https://github.com/envoyproxy/ai-gateway/issues/90).