Size workload containers from the flavor

[vitramir]

The catalog declared flavors, this runner reported them, and the platform
resolved and billed by them -- while every container was created with no
resources at all, so pods came out BestEffort whatever the flavor said.

A flavor now carries two budgets: resources for the workload's main
container and sidecarResources for each of its sidecars, so a workload
asks for a size rather than a per-container budget. The name arrives on
StartWorkloadRequest and resolves against this runner's own catalog; an
unknown name fails the start rather than silently landing unsized, and a
workload naming none is left as it was.

Init containers stay unsized on purpose. Kubernetes takes a pod's request
as max(sum of containers, max of init containers), so sizing them would
make a workload reserve its flavor plus its bootstrap.

The shipped flavors request a typical footprint and limit the ceiling
rather than requesting the ceiling itself. Reserving it stranded most of
a node -- five workloads held 11.3Gi of 15.5Gi on a 16Gi node, and
everything after them stopped scheduling.

Depends on agynio/api#198 — CI cannot build until that proto field is on the BSR.

Verified on the local bundle VM: workload pods went from BestEffort to correctly sized, and the svc_k8s_runner e2e suite is 8/8.