refactor(cloud): thread probe identity explicitly instead of pinning process env

[sourcehawk]

Description

Towards #44

The launcher-side cloud identity probe pinned each provider's expected-identity env via process-global os.Setenv (serialized behind a mutex) because the providers read that env through os.Getenv in-process. Mutating process-global env from a request path is a concurrency footgun. This threads the pinned identity and the subprocess credential env explicitly instead, so concurrent probes for different sources never share state.

It is an internal threading refactor: the profile schema (CloudSource), the ProbeSource(ctx, Source) signature, and all launcher behavior are unchanged. The serve --kind=cloud subprocess still authenticates from its injected env.

Changes

• Provider.Identity and cloud.Probe take the pinned identity (expected) and the subprocess env explicitly; the gcp and aws implementations validate the resolved identity against expected instead of reading their own os.Getenv.
• ProbeSource no longer mutates the launcher process env (and drops the serializing mutex). It builds the subprocess credential env explicitly — base PATH/HOME plus the provider's declared config-dir passthrough names carried from os.Environ, with the source credential var overlaid — and threads the pinned identity into cloud.Probe.
• A uniform TRIAGENT_CLOUD_EXPECTED_IDENTITY env carries the pinned identity for both providers, set by cloudSourceEnv alongside the per-provider credential env (gcp impersonation target, aws assume-role profile) and read once by runCloud in the serve subprocess. The aws-only expected-role-ARN env is removed.

Challenges

The serve subprocess and the launcher-side probe sit in different processes with different ambient env. The subprocess legitimately reads its injected credential env from os.Environ (via Server.subprocessEnv()), but the launcher process does not hold the pinned credential — which is why the old code mutated global env to fake it. The fix splits the env-building responsibility: the subprocess path keeps reading os.Environ, while ProbeSource constructs the credential env explicitly per source and passes it through cloud.Probe, so neither path mutates shared state.

Testing

make test-go is race-clean and green; make lint reports 0 issues. Added a test proving ProbeSource leaves the process env untouched (a sentinel, AWS_PROFILE, and the gcp impersonation env all read identically after probing both providers), a sourceEnvFor overlay test (source credential overrides the operator's ambient value; undeclared env never crosses the boundary), and a nil-provider contract-error test on Probe. The provider identity tests now thread expected directly instead of setting env. The existing harness_security_test.go minimal-env guarantees for run_cli are unaffected.

🤖 Generated with Claude Code