feat: expand secret/env refs in working_dir (and data_dir, host_path)

[tjsingleton]

Summary

${env:VAR} and ${keyring:...} references are expanded for env, args, and headers in NewClientWithOptions (internal/upstream/core/client.go), but working_dir is never passed through ExpandSecretRefs. The same gap exists for the top-level data_dir config field and Docker isolation host_path volume mounts.

Reproduction

Config:

{
  "working_dir": "${env:IH_HOME}",
  ...
}

The literal string ${env:IH_HOME} is passed as the working directory instead of the resolved path, causing the server to fail to start if the directory doesn't literally exist.

Expected Behavior

${env:...} and ${keyring:...} references in working_dir, data_dir, and host_path are resolved the same way they are for env, args, and headers.

Suggested Fix

In NewClientWithOptions, add a resolution block for WorkingDir after the existing Headers block:

// Resolve secrets in working directory
if resolvedServerConfig.WorkingDir != "" {
    resolvedValue, err := secretResolver.ExpandSecretRefs(ctx, resolvedServerConfig.WorkingDir)
    if err != nil {
        logger.Error("Failed to resolve secret in working_dir", ...)
    } else {
        resolvedServerConfig.WorkingDir = resolvedValue
    }
}

Similar fixes needed for:

• Top-level Config.DataDir
• IsolationConfig.Volumes[].HostPath

Context

Validated against commit f204be8.

[Dumbris]

Thank you @tjsingleton! Your PR #336 has been merged. The secret/env ref expansion now covers all ServerConfig string fields (including working_dir, data_dir, host_path, etc.) via the reflection-based approach. Really appreciate the thorough implementation and tests!