Pi sub-agent workspace isolation failure within Omnigent.

## Summary

A `pi` sub-agent does not run in the session's workspace. It launches in the directory the **omnigent server was started from**, ignoring the per-session workspace that the native (`codex-native` / `claude-native`) harnesses correctly honor. When the server's launch directory differs from a session's workspace, every `pi` dispatch for that session operates on the wrong repository.

## Environment

- omnigent 0.1.0 (uv tool install), macOS (arm64), Python 3.12
- Setup: bundled `examples/polly` orchestrator with `pi`, `codex`, `claude_code` sub-agents
- All three agents declare the same `os_env`:
```yaml
os_env:
type: caller_process
cwd: .
sandbox:
type: none
```

## Repro

1. Start the omnigent server from directory `REPO_A`.
2. Start a session whose workspace is a different directory, `REPO_B` (e.g. launch the session from `REPO_B`). `GET session info` reports `workspace: REPO_B`.
3. Dispatch a read-only probe to each sub-agent asking it to print its current working directory.

## Expected

All sub-agents run in the session workspace `REPO_B`.

## Actual

- `codex-native` and `claude-native` workers run in `REPO_B` (correct).
- `pi` runs in `REPO_A` (the server's launch directory), not `REPO_B`.

This is deterministic: every `pi` dispatch in the session lands in `REPO_A` until the server is restarted from a different directory.

## Evidence (from live process environments)

- The native CLI subprocess (codex) has the session workspace injec...