fix(ruby): apply launchConfig.env to the debuggee spawn env (#318)

[debugmcpdev]

Fixes #318.

Problem

env passed via dapLaunchArgs was silently dropped on the ruby launch path. It survives transformLaunchConfig into the DAP launch request, but with rdbg --open -c -- ruby <script> the debuggee is already running when that request arrives — the launch response is effectively an ack. Ruby is the only adapter with this gap: python/js/go/rust/dotnet/java all apply user env when the debug adapter launches the debuggee at DAP-launch time (verified per adapter).

Everything upstream and downstream was already correct — dapLaunchArgs.env lands at AdapterConfig.launchConfig.env with no shadowed-key warning (env is deliberately listed as a legitimate DAP launch key in server.ts), and the spawn plumbing passes AdapterCommand.env verbatim. The single break was buildAdapterCommand never reading it.

Fix

Merge launchConfig.env into the spawn env, user values last:

env: {
  ...process.env,
  RUBY_DEBUG_DAP_SHOW_PROTOCOL: process.env.DEBUG ? '1' : '0',
  ...(launchConfig.env ?? {})
}

An explicit user value wins over both inherited process.env and adapter defaults (a user setting RUBY_DEBUG_DAP_SHOW_PROTOCOL explicitly presumably intends it). Env inherits through bundle exec automatically; no interaction with the #317 -r prelude (argv vs env). Attach mode untouched — the target process is already running (documented).

Tests

• Hard e2e (mcp-server-smoke-ruby.test.ts): launch fizzbuzz with dapLaunchArgs: { env: { MCP_TEST_ENV_318: 'hello-318' } }, evaluate ENV['MCP_TEST_ENV_318'] at a breakpoint. Red against the pre-fix build ("nil"), green after.
• Unit: merge order pinned — user env reaches command.env, overrides an inherited process.env key, and overrides the adapter default; no-env case pins today's behavior. Added vi.unstubAllEnvs() to the suite's afterEach since env stubbing is now in play.
• Full ruby suite green (unit, integration, all 5 smoke e2e tests including [BUG] comprehensive e2e matrix: ruby get_output marker '1: 1' not captured mid-run (soft FAIL cell) #317's); docs updated (docs/ruby/README.md new "Environment variables" section).

Sibling gap filed as #320: launchConfig.cwd is dead on the ruby launch path the same way (AdapterCommand has no cwd channel; spawn layer already supports it).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!