unitree-go2-multi and unitree-go2-multi-teleop fail startup because no modules are deployed

### Description

## Summary

Both `unitree-go2-multi` and `unitree-go2-multi-teleop` fail during startup because the resulting blueprint has no deployed modules.

The worker pool starts successfully, but no modules are deployed before `ModuleCoordinator.build_all_modules()` is called.

Both blueprints reproduce the same failure independently.

## Reproduction

### unitree-go2-multi

```bash
cd ~/dimensional/dimos

uv run pytest \
  'dimos/robot/test_blueprint_startup.py::test_blueprint_starts[unitree-go2-multi]' \
  -m '' \
  -vv -s --tb=long
```

### unitree-go2-multi-teleop

```bash
uv run pytest \
  'dimos/robot/test_blueprint_startup.py::test_blueprint_starts[unitree-go2-multi-teleop]' \
  -m '' \
  -vv -s --tb=long
```

## Actual behavior

For `unitree-go2-multi`, startup reaches:

```text
Starting the modules
Worker pool started. n_workers=2
Shutting down all workers...
All workers shut down
```

No module deployment occurs between starting and shutting down the worker pool.

`ModuleCoordinator.build_all_modules()` then fails because `_deployed_modules` is empty:

```text
ValueError: No modules deployed. Call deploy() before build_all_modules().
```

The startup test reports:

```text
Blueprint 'unitree-go2-multi' exited during startup with code 1.
```

`unitree-go2-multi-teleop` independently reproduces the same sequence and exception:

```text
Starting the modules
Worker pool started. n_workers=2
Shutting down all workers...
All workers shut down

ValueError: No modules deployed. Call deploy() before build_all_modules().
```

## Expected behavior

These registered blueprints should either:

1. deploy the modules required for their respective Go2 multi-robot configurations, or
2. not be registered as runnable blueprints if they are incomplete/deprecated placeholders.

`ModuleCoordinator.build_all_modules()` should not be reached with an empty blueprint during normal execution of these registered blueprint names.

## Notes

This appears to be one issue family affecting at least:

- `unitree-go2-multi`
- `unitree-go2-multi-teleop`

Both were reproduced independently, so this does not appear to be test-order or full-suite state leakage.

This is also distinct from the hardware/config-dependent startup failures tracked in #4130. These two blueprints fail before attempting to connect to Go2 hardware because no modules are deployed at all.

The underlying cause is likely in the blueprint definitions or registration/configuration path that results in an empty blueprint.

## Suggested labels

`bug`

---

## QA provenance clarification

This issue was discovered during a macOS release QA pass using an **additional local runtime startup harness** that launched registered blueprints and checked whether they remained alive through startup.

The local QA harness was:

```text
dimos/robot/test_blueprint_startup.py
```

That file was **not tracked on `main`** and was not an existing DimOS CI test.

The underlying failure documented in this issue was subsequently reproduced in isolation, so the bug itself remains valid. This clarification is only to correct the original issue wording where it may have implied that `test_blueprint_startup.py` was already part of the repository or CI.

Runtime startup coverage itself is being discussed separately in #4130.


Navigation Menu

Uh oh!

unitree-go2-multi and unitree-go2-multi-teleop fail startup because no modules are deployed #4133

Description

Summary

Reproduction