Forward workload identity to volume drivers via mount config

[Viktor-Velkov]

Summary

Rep already knows the authoritative workload identity (process GUID for LRPs, task GUID for Tasks) at the moment it calls volumeManager.Mount, but does not forward it to the volume driver. Volume drivers that validate a mount against the workload's service bindings therefore have to reconstruct that identity out-of-band (e.g. a cfdot actual-lrps --cell-id cell-wide scan followed by a DesiredLRP fetch), which is slow (~1–2s typical, seconds under load) and requires sudo + shell tooling on the cell.

This PR enriches the mount config map with the workload identity Rep already holds, before calling Mount:

• _workload_guid — process_guid (LRP) or task_guid (Task)
• _workload_type — "lrp" or "task"

No protocol change is required — the keys ride the existing config map, which the Docker plugin's Create call already forwards to the driver. A binding-validating driver can then read the identity directly instead of reconstructing it.

Backward compatibility

Breaking change? No. The change is additive:

• the original config map is not mutated (a copy is enriched);
• containers without a lifecycle tag are returned unchanged;
• volume drivers that do not read the keys ignore them;
• the underscore prefix distinguishes these injected keys from broker-supplied config.

Tests

• Unit tests cover LRP, Task, missing-lifecycle and nil-config cases.
• Existing containerstore mount tests continue to pass.
• Validated end-to-end against a binding-validating volume driver.

Related

Design discussion (cross-component contract, alternatives considered): #1192