feat(providers): define shared restrictions for profile environment keys #5521

User Story

I use OpenShell sandboxes with Google/Vertex provider profiles. I need consistent restrictions on profile environment variables, with migration guidance for existing profiles.

This follow-up tracks the shared environment-key restriction requested in the review of #3775, including compatibility for existing custom profiles.

Problem Statement

Provider profiles can select workload environment variable names through files[].env_var. PR #3775 adds environment.config and environment.fixed, which allow configuration-derived and literal defaults. Current validation checks names, bounds, and collisions but does not define a shared restriction for variables that control program loading, startup, proxy routing, certificate trust, or OpenShell runtime behavior.

This concern predates #3775 through file environment variables and applies across provider profiles. The PR expands the values profiles can express. Importing profiles already requires workspace or platform administrator privileges; this proposal does not establish a sandbox escape or a network-policy bypass.

Impact / Why This Matters

Administrators currently review profile contents manually to identify settings that affect workload behavior beyond provider configuration. A restriction covering only one provider or declaration field would leave equivalent capabilities available elsewhere.

Some affected settings also serve legitimate uses, including corporate proxies and custom certificate authorities. Immediately rejecting previously accepted keys would break custom profiles. Dropping those settings silently could also change workload behavior.

Proposed Design

• Define and document a consistent policy for environment destinations in environment.config, environment.fixed, and files[].env_var, independent of profile ID. Inventory other provider environment outputs, including credential destinations, and document their treatment.
• Evaluate the names and prefixes proposed in the original review: OPENSHELL_*, LD_*, DYLD_*, PATH, BASH_ENV, ENV, NODE_OPTIONS, PYTHONPATH, PYTHONSTARTUP, proxy variables, TLS trust variables, and OTEL_EXPORTER_*. Determine the exact scope and supported alternatives before enforcing it.
• Apply equivalent rules to YAML and protobuf profile input. Diagnostics should identify the profile, declaration field, restricted destination, and migration guidance.
• Specify what happens to existing stored profiles, profile updates, and attached sandboxes after an upgrade. Choose a documented warning/deprecation period or enforcement in a breaking release, with migration instructions. Avoid silently removing existing settings.

Suggested UX

Illustrative diagnostic for human review; the final restricted set remains to be decided:

profile 'example': environment.fixed.NODE_OPTIONS is restricted because it controls runtime startup; configure this setting through the documented workload configuration path.

Acceptance Criteria

• The restricted names/prefixes and their rationale are documented, along with supported workflows for legitimate proxy, trust, and runtime settings.
• Equivalent restricted destinations receive consistent treatment across all three declaration fields and across profile IDs, for YAML and protobuf input.
• Other provider environment-output paths have documented treatment or explicit exclusions.
• Allowed provider defaults and managed-file variables continue to work.
• Diagnostics identify the affected profile, field, key, and corrective action.
• Upgrade behavior for stored profiles and attached sandboxes is documented and verified, including any deprecation period or breaking-release requirement.

Alternatives Considered

• Continue manual review alone: preserves compatibility but provides no consistent validation or diagnostics.
• Restrict only new environment defaults or selected providers: leaves the existing file-variable path and other profile IDs with different rules.
• Use an OpenShell gateway interceptor: evaluate whether it covers all profile mutation and source-loading paths. Prefer it if it provides the required coverage; a request-only check would leave uncovered inputs.

Related: #3775, #3442. Original scope and candidate keys: earlier review.