Support actortemplate secret env

[Eitan Yarmush (EItanya)]

A couple of TODOs/Discussions which I think are important to have based on these changes.

1. Do we need a caching client for this to avoid calling the apiserver every time?
2. Where/how do we want to resolve secrets generally? I think there are good arguments to be made for the control-plane OR the "node" component. In my mind this also related to: Design: How should substrate use (or not use) namespaces in a Kubernetes cluster? #18

Fixes #15

It's a good idea to open an issue first for discussion.

• [ x ] Tests pass
• [ x ] Appropriate changes to documentation are included in the PR

[ensemble-hcl]

Reading PR #20 alongside Taahir Ahmed (@ahmedtd)'s #10/#51 (image-pinning admission policy) and Tim Hockin (@thockin)'s #18 (namespace design), there's a coherent "production-ready ActorTemplate" thread across the three surfaces that may be worth surfacing while TODO 2 here is still open.

1. Image pinning at admission (Prevent user from creating ActorTemplates with un-pinned images #10/ActorTemplate: Enforce that all images must be pinned #51): cluster-global policy; no tenancy nuance.

2. Secret/ConfigMap env resolution (this PR — TODO 2: control-plane vs atelet): control-plane resolution keeps atelet's footprint minimal but binds the substrate manager to each workload's secret namespace. Atelet resolution inverts that — the manager stays clean of tenant secrets, but atelet inherits namespace-scoped k8s creds.

3. Namespace model (Design: How should substrate use (or not use) namespaces in a Kubernetes cluster? #18): the answer there shapes TODO 2 materially. If ActorTemplate's effective tenant boundary is the resource namespace (per the "namespaced CR, cluster-watcher" framing in Design: How should substrate use (or not use) namespaces in a Kubernetes cluster? #18), control-plane resolution needs an explicit namespace-scope mechanism in the resolution path. Atelet resolution has the boundary naturally because atelet is per-actor.

The caching question (TODO 1) interacts: an apiserver client at atelet sees only its actor's namespace and is naturally bounded; a centralized cache in the manager has to handle namespace fan-in plus tenant invalidation.

No strong opinion on which side wins, but #18's resolution may want to land first or co-evolve since it constrains TODO 2's design space.

(Alex Bulankou (@AlexBulankou) asked me to take a closer look here.)