feat(ui): populate agent env from connection envMappings on grant

[matoushavlena]

Summary

Brings GOOGLE_WORKSPACE_CLI_TOKEN back for the google-workspace agent without re-adding it to the Helm template. When a user grants a gmail, google-drive, or any other Google Workspace connection in the Configure Agent dialog, Humr copies the connection's declared envMappings into the agent's editable env list. The user can then edit or remove the entries like any custom env.

Requires OneCLI 0.0.20+ (kagenti/onecli#16, merged) which declares envMappings on the app registry and returns them on GET /api/connections. Humr image bumped accordingly in deploy/helm/humr/values.yaml.

Why

Two things the previous design tried got collapsed into one:

• Who owns the provider → env knowledge? → OneCLI's app registry. Humr has zero provider-specific code paths.
• Where do the envs end up? → On the agent (agentSpec.env), where they already live for every other per-agent env. No new injection pipeline, no reconciler changes, no connection-side metadata.

Result: the only Humr change is a UI interaction (populate on grant, auto-clean on untouched ungrant) + a pass-through of the envMappings field from OneCLI's response to the view.

Grant / ungrant behavior

• Grant: append the app's declared envMappings to the editable env list. Skip entries whose name is already present (user-set wins).
• Ungrant: remove entries the app contributed only if both conditions hold —
  • Untouched (name + value still match the declared mapping)
  • Not still needed by any other currently-granted app (shared envs like GOOGLE_WORKSPACE_CLI_TOKEN across Gmail + Drive stay)
• Edited entries are preserved — an edited value signals user intent that toggling should not undo.

Logic is extracted as pure helpers in packages/ui/src/dialogs/connection-env-helpers.ts and covered by 10 vitest cases across all four grant/ungrant × touched/shared permutations plus the OneCLI-placeholder-change case.

What changes

• api-server-api/connections/types.ts — AppConnectionView.envMappings?: EnvMapping[] for UI consumption.
• api-server/connections-service.ts — passes through OneCLI's joined envMappings verbatim. Tests use a fictional provider fixture (acme-app / ACME_TOKEN) — no Google-specific coupling.
• ui/dialogs/connection-env-helpers.ts (new) — pure envsToAddOnGrant / envsAfterUngrant helpers.
• ui/dialogs/edit-agent-secrets-dialog.tsx — toggleApp calls the helpers; functional updater reads fresh env state.
• ui/__tests__/unit/connection-env-helpers.test.ts (new) — 10 unit tests.
• ui/views/connections-view.tsx — shows env names on each connection row so users see what a grant will contribute.
• deploy/helm/humr/values.yaml — OneCLI image 0.0.19 → 0.0.20.
• docs/google-workspace/README.md — describes the grant-time flow.

Verification plan

• mise run check passes (eslint + tsc + go build/vet + helm lint/render)
• mise run test passes (controller + ui + agent-runtime; 34 ui tests including 10 new)
• mise run api-server:test:unit passes (34 tests)

Manual end-to-end probe (requires OneCLI 0.0.20 running):

1. Deploy: mise run cluster:install
2. In OneCLI, connect Gmail or Google Drive (OAuth flow).
3. Create or open a google-workspace agent.
4. Click Configure → Connections tab → grant the Google connection.
5. Switch to Environment tab → verify GOOGLE_WORKSPACE_CLI_TOKEN=humr:sentinel appears in the editable list.
6. Save.
7. mise run cluster:kubectl -- exec <agent-pod> -- env | grep GOOGLE_WORKSPACE → env present.
8. From the agent pod: gws drive files list → returns real Google data.
9. Reopen Configure, ungrant the connection, Save. Env entry should be removed automatically (because untouched).
10. Re-grant + edit the value → ungrant → env entry stays (user edit preserved).

Existing google-workspace instances

Pods deployed before this change had GOOGLE_WORKSPACE_CLI_TOKEN injected by the helm template (removed in ADR-024). After upgrading to this release they will have no token env until the user re-opens Configure Agent and grants a Google connection (or manually sets the env). Release-note suggestion:

Google Workspace agent users: after upgrading, open each google-workspace agent → Configure → grant your Google Drive / Gmail connection. The env var injection moved from the template to grant-time and needs to be re-triggered once per agent.

Follow-up (out of scope here)

• Anthropic secrets still use Humr-side ANTHROPIC_OAUTH_ENV_MAPPING / ANTHROPIC_API_KEY_ENV_MAPPING constants. Long-term we should move those declarations into OneCLI's secret-type registry (symmetric with this PR) so Humr owns zero env name knowledge.