`GetSecretsRequest` carries no caller context, making project-local plugin backends impossible

The current GetSecretsRequest proto contains only pattern:

message GetSecretsRequest {
  string pattern = 1;
}

This means a plugin daemon has no way to know who is asking or from where. For secret backends that are inherently project-local (encrypted files checked into a repo, .env files co-located with compose.yaml) this is a dead end. The plugin either serves a single global config or has to resort to global mutable state (a shared config file) that breaks under concurrent projects.

Concrete example: a SOPS plugin that decrypts secrets.sops.env files. The file lives in the project directory. The plugin needs to know the calling project's working directory to find it. There is no way to get this today.

Proposal: add optional caller context to GetSecretsRequest:

message GetSecretsRequest {
  string pattern = 1;
  optional CallerContext context = 2;
}

message CallerContext {
  string working_directory = 1;
  string compose_project   = 2;
  map<string, string> labels = 3;
}

Docker and Compose already know the project directory at secret resolution time. Passing it through costs nothing and unlocks an entire class of local-first secret backends.

Start by locating the GetSecretsRequest proto and tracing secret resolution through Docker and Compose, where the project directory is already known. Review how plugin requests are propagated, then define and validate the CallerContext contract so project-local backends can receive it without breaking callers.