Decouple runner package imports from ACP/tool runtime dependencies

## Summary

Importing lightweight modules under `qwenpaw.app.runner.*` currently executes the package `__init__.py`, which eagerly imports the full runner stack. That transitively imports `QwenPawAgent`, built-in tools, and ACP-related modules. In a partially installed development/test environment this can fail before the target lightweight module is even imported.

## Observed while testing

During the `/goal` MVP work, a pure state/dispatch helper was initially placed under `qwenpaw.app.runner.goal_dispatch`. A focused unit test importing that module failed during collection because Python first executed `qwenpaw.app.runner.__init__`, which pulled in the full runner/agent/tool stack and raised:

```text
ModuleNotFoundError: No module named 'acp'
```

The dependency itself is declared by the project (`agent-client-protocol>=0.9.0`), and installing the project editable resolves the missing package. The issue here is the import coupling: tests or app helpers that only need lightweight runner-adjacent utilities should not have to import the entire runtime stack.

## Why this matters

- Makes focused unit tests brittle in local or minimal environments.
- Makes package import boundaries harder to reason about.
- Forces unrelated helpers to depend on optional/heavy runtime concerns.
- Encourages moving modules out of `qwenpaw.app.runner` purely to avoid import side effects.

## Possible approaches

- Make `src/qwenpaw/app/runner/__init__.py` lighter by avoiding eager imports of heavy runtime modules.
- Export heavy classes such as `AgentRunner`, routers, and managers through lazy imports or explicit submodule imports.
- Move ACP/tool imports closer to the code paths that actually need them, instead of importing them during package initialization.
- Add a small import-boundary test that verifies lightweight runner utilities can be imported without constructing the full agent/tool stack.

## Non-goals

- This does not require changing runtime behavior.
- This does not require removing ACP support.
- This is separate from the `/goal` MVP implementation; it is a developer experience and import architecture cleanup.

## Related context

Related to the testing/import-boundary observation from #4443.