fix(server/execute): unwrap Paperclip {type,value} env entries before spawn

[tamermina]

Summary

• config.env values from Paperclip arrive as {type: "plain"|"secret", value: string} objects, not plain strings
• Object.assign(env, userEnv) at src/server/execute.ts:425 (HEAD 937ea71) spreads these objects directly into the spawned process env
• Node coerces each object to the literal string "[object Object]", breaking every downstream consumer: PAPERCLIP_API_KEY auth fails, PAPERCLIP_RUN_ID is corrupted, all custom user env vars are useless

Reproduce

Set an env var in a Paperclip agent's adapterConfig.env (any key/value). Spawn the adapter and console.log(process.env.YOUR_KEY) inside the Hermes process — you'll see "[object Object]" instead of the string value. The same applies to every var Paperclip stores in the wrapped shape.

Fix

Replace Object.assign(env, userEnv) with a for-loop that unwraps {type, value} entries before assigning:

const userEnv = config.env as
  | Record<string, string | { type: "plain" | "secret"; value: string }>
  | undefined;
if (userEnv && typeof userEnv === "object") {
  for (const [key, raw] of Object.entries(userEnv)) {
    if (raw && typeof raw === "object" && "value" in raw) {
      // Paperclip wraps env values as {type: "plain"|"secret", value: string}
      env[key] = String((raw as { value: unknown }).value);
    } else if (typeof raw === "string") {
      env[key] = raw;
    }
  }
}

The typeof raw === "string" branch preserves the legacy path for any caller already passing plain strings.

The type annotation is widened from Record<string, string> to Record<string, string | {type: "plain"|"secret"; value: string}> — this accurately reflects the actual runtime shape Paperclip passes and is a strictly safer cast than the existing one (which silently lies to the compiler).

Verification

• npx tsc --noEmit — clean, zero errors
• npm run build (i.e. tsc) — clean, zero errors
• ESLint skipped: eslint is not in devDependencies and there is no eslint.config.* file in the repo — the lint script is broken upstream independent of this PR
• Equivalent fix has been running in production on our self-hosted deployment for ~3 weeks as an in-container patch (sentinel PAPERCLIP-UNWRAP-ENV-PATCH in our deploy script). 21 agents across 3 companies (UNOA, CHAA, REVĪV) depend on the fixed behavior for every heartbeat run. Zero regressions observed in that period.

Risk

Low. The unwrap path only activates when raw is an object with a value key — which is exactly the shape Paperclip produces. Plain-string values fall through to the existing assignment. The fix cannot affect callers that already pass strings correctly.