on submidule-heavy repos, worktree create hangs ~30s → runtime_unavailable and orphans a git worktree on submodule-heavy repos under load (macOS 1.4.121)

## Summary

`orca worktree create` intermittently fails on a repository that contains **many git submodules**: it hangs for ~30s, then returns `runtime_unavailable` (`runtimeId: null`), **and leaves behind a git-level worktree that Orca never registers** (an orphan). The identical operation on a repository with **no** submodules succeeds in under a second.

## Environment

- Orca 1.4.121, macOS
- Invoked via the CLI: `orca worktree create … --json`

## Reproduction (controlled A/B, identical concurrent load)

Under moderate-to-heavy concurrent load (tens of worktrees/terminals active):

1. **Submodule-heavy repo** — `orca worktree create --repo …`
hangs ~30s (CPU-idle, i.e. I/O-blocked), then returns:
```json
{"error": {"code": "runtime_unavailable", "message": "runtime_unavailable"}, "_meta": {"runtimeId": null}}
```
However, a git worktree + branch **were** created on disk and are **not** listed by `orca worktree list` (orphaned — they must be cleaned up manually with `git worktree remove --force` + `git branch -D`).

2. **Plain repo (no submodules)** — the same command against a submodule-free repo, at the same moment under the same load, succeeds in ~0.7s and is registered cleanly.

The only variable that differs between the two arms is the target repo (submodule-heavy vs. plain), so the failure correlates with **submodule handling during worktree creation**, not with generic runtime load.

## Impact

- The CLI reports failure while a real git worktree is left behind → orphan worktrees accumulate and need manual cleanup.
- Scripts/agents that create child worktrees on submodule repos cannot rely on the create call succeeding under load.

## Notes

- No `blockedReason` field appears in the failure response.
- Not yet isolated to a specific submodule step (e.g. submodule init/checkout during create). Happy to provide additional detail or logs.