Implement RunnerService ListWorkloads/ListVolumes + propagate orchestrator label.* properties

[rowan-stein]

User request

Orchestrator is logging RPC errors against docker-runner:

• unknown method ListWorkloads for service agynio.api.runner.v1.RunnerService
• unknown method ListVolumes for service agynio.api.runner.v1.RunnerService

This breaks reconciliation and contributes to workloads not starting/restarting correctly when multiple agent threads are running.

Specification (from research)

Architecture (agynio/architecture) expects the runner to expose RunnerService.ListWorkloads and RunnerService.ListVolumes.

1) Implement missing gRPC methods

In docker-runner, add implementations for:

• RunnerService.ListWorkloads(ListWorkloadsRequest) returns (ListWorkloadsResponse)
• RunnerService.ListVolumes(ListVolumesRequest) returns (ListVolumesResponse)

Behavior:

• ListWorkloads: list Docker containers that belong to orchestrated workloads (filter by labels), and return WorkloadListItem { instance_id, workload_key } for each.
• ListVolumes: list Docker volumes that belong to orchestrated volumes (filter by labels), and return VolumeListItem { instance_id, volume_key } for each.

2) Ensure orchestrator-provided labels are applied to Docker containers

The orchestrator sends labels in request.AdditionalProperties using a label. prefix (e.g., label.workload_key, label.thread-id, etc.).

docker-runner must:

• Extract label.* entries from request.additionalProperties
• Strip the label. prefix
• Apply them as Docker container labels
• Ensure volume labels are applied similarly when Docker volumes are created (so ListVolumes can return volume_key).

3) Acceptance criteria

• Orchestrator no longer logs Unimplemented for ListWorkloads/ListVolumes when using docker-runner.
• The runner returns workload_key / volume_key labels correctly.
• Orchestrator can reconcile actual vs desired state (no stale workloads due to inability to list actual containers/volumes).

Notes:

• Related orchestrator issue also involves a managed_identities.identity_id uniqueness problem in ziti-management; that is tracked separately at the service/DB level (migration 0007_make_identity_id_non_unique.sql).