docs: define Agent Context Infrastructure terminology

[moonlight16]

Summary

Define Agent Context Infrastructure as the capability provided by Context Service.

Context Service remains the component name. This PR updates the README, vision, design, and API documentation to use a clearer name for the broader capability.

Why

“Context” is an overloaded term. It is commonly used for an LLM context window: the bounded set of tokens supplied to a model for a request. That is distinct from the context managed by this project.

The project’s existing vision defines agent context more broadly. It includes:

• execution state
• workspaces
• memory
• knowledge
• artifacts

“Memory Context Infrastructure” was considered, but it is too limiting because memory is only one part of this existing scope.

“Agent Context Infrastructure” makes the intended consumer explicit and distinguishes this capability from LLM context windows without narrowing it to memory alone.

Terminology

• Agent Context Infrastructure: the overall capability
• Context Service: the component providing that capability
• context: a resource managed through the API

Why the interfaces retain context

“Agent Context Infrastructure” names the overall capability, not an individual API resource or implementation component.

The API manages concrete context resources. Context Service is the component currently providing the capability, while the broader infrastructure can include additional components over time.

Renaming the repository, service, API paths, Kubernetes resources, and configuration would create substantial compatibility churn without making the managed resource clearer.

Scope

This is a terminology clarification. It does not propose a new architecture or change the project’s existing vision.

It does not rename or modify:

• the repository or Go module
• container images or Kubernetes resources
• API paths
• environment variables
• runtime behavior