Define mutability/validity/cacheability for API responses

Our implementation currently has a workflows that put API server calls on the hot path.

A example is that the a Router request to an Actor calls `ResumeActor`. This puts ATE API at the center of the operation which will be hard to scale. We should add some notion of mutability/cacheability/validity of state to the system so state can be cached. These are not documented in the .proto today.

In addition, we need to be more specific as the RPC response has fine grain validity within the message. Example:

```proto
// From ateapi.proto
message Actor {
...
string actor_template_namespace; // <-- this field can be cached indefinitely as it will never change
...
Status status = 4; // <-- this field would have an expiry of ??? ms?

// Fields that will change, but have TTL of ??? ms
string ateom_pod_namespace = 5;
string ateom_pod_name = 6;
string ateom_pod_ip = 7;
...
```

Proposal:

We should minimally document which fields are immutable and can be cached forever.

We should identify state that could/should be cached and what the strategy is for indicating validity.

Some potential (bad) ideas: separate cacheable data into a nested message. Add some standard set of cache metadata (strategy, valid until, TTL etc). I think one requirement is that the server set these fields explicitly vs rely on implicit constants baked into the codebase. We may want to consider having this metadata on a per-response basis a la HTTP. The issue with using HTTP response caching semantics is that it is very broad and some pieces of state may have different caching requirements. As our API structures are somewhat designed to avoid round trips, we may not be able to split resources in a way that matches their ability to be cached.