fix: correct terminology and flag inconsistencies in docs

COLLABORATING.md

@@ -90,7 +90,7 @@ community, and it helps prevent silos from forming within the community.
 
 We want to move quickly, but we also want to be respectful of each other's
 time.  For the sake of consistency, this project's "working hours" are Monday
-to Friday, 8am to 8pm, US Pacific Time (GMT-7). Please avoid merging PRs late
+to Friday, 8am to 8pm, US Pacific Time (PT). Please avoid merging PRs late
 at night or on weekends, unless it is an urgent fix.  This allows for people to
 have a better work-life balance and prevents burnout.  If you do need to merge
 something outside of normal working hours, please try to give a heads up to the

README.md

@@ -115,7 +115,7 @@ hack/install-ate-kind.sh --deploy-demo-counter
 go install ./cmd/kubectl-ate
 
 # create a counter actor and demo it
-kubectl ate create actor my-counter-1 --template ate-demo-counter/counter
+kubectl ate create actor my-counter-1 --template=ate-demo-counter/counter
 
 # port-forward the network router to bind to local port `8000`
 kubectl port-forward -n ate-system svc/atenet-router 8000:80
@@ -146,7 +146,7 @@ curl -X POST -H "Host: my-counter-1.actors.resources.substrate.ate.dev" -i http:
    go run ./tools/setup-gcp --all
    ```
 
-4. Deploy the Agent Substrate system to your cluster (remember to navigate back to root directory of this repo before running the following commands):
+4. Deploy the Agent Substrate system to your cluster:
    ```bash
    ./hack/install-ate.sh --deploy-ate-system
    ```

docs/api-guide.md

@@ -121,6 +121,7 @@ metadata:
 spec:
   # No sandbox/runsc config here — the binaries come from the WorkerPool's
   # SandboxConfig (see section 3).
+  # GKE clusters: use gcr.io/gke-release/pause. Other clusters: registry.k8s.io/pause:3.9
   pauseImage: "gcr.io/gke-release/pause@sha256:bcbd57ba5653580ec647b16d8163cdd1112df3609129b01f912a8032e48265da"
   containers:
   - name: agent

docs/architecture.md

@@ -52,7 +52,7 @@ Standard Kubernetes Pods are simply too heavy for many agentic workloads.
 ### Terminology: "Actor"
 
 Agent Substrate seeks to solve these problems for "agent-like" workloads.
-Often we simply say "agents", but it's important clarify that "agent-like"
+Often we simply say "agents", but it's important to clarify that "agent-like"
 workloads are not necessarily literally AI agents.  In most of the docs we
 instead use the term "actor" to refer to an instance of an agent-like workload.
 
@@ -167,7 +167,7 @@ There are a few different personas that interact with the system:
   2) **Substrate admins**: These are the people who set up and own the Agent
      Substrate instance(s) in a Kubernetes cluster.  They are obviously aware
      that it is running in a Kubernetes cluster, and are responsible for
-     configuring the Kubernetes resources for it (such as WarmPools).
+     configuring the Kubernetes resources for it (such as WorkerPools).
 
   3) **Agent developers**: These are the people who deploy agents into a substrate
      for users or higher-level systems to consume. They might have to be aware