Make senpi resolve omo-owned config/state from ~/.omo alongside ~/.senpi

## Problem

A senpi install driven by omo reads user-scope state from **three unrelated directories**:

| Directory | Owner | Contents |
|---|---|---|
| `~/.senpi/agent/` | senpi (`packages/coding-agent/src/config.ts`, `CONFIG_DIR_NAME` from `package.json → piConfig.configDir`) | `settings.json`, `models.json`, `auth.json`, `sessions/`, `extensions/`, `skills/`, `themes/`, `prompts/` |
| `~/.omo/` | omo runtime | `rules/`, `plans/`, `teams/`, `runtime/`, `codegraph/`, `lsp-daemon/`, `senpi-task/`, `worktrees/`, `loop/` |
| `~/.config/omo/` | omo config (`omo-config-core`) | `omo.jsonc` — categories, agents, task, teams |

There is currently no relationship between them beyond `omo-senpi`'s installer writing its plugin path into `~/.senpi/agent/settings.json` (`packages/omo-senpi/src/install/install-senpi.ts`) and `config-watch` avoiding senpi's protected paths.

Consequence: to configure "one" agent you edit files in three places, and there is no single answer to "where does my omo-on-senpi setup live". Nothing reads `~/.omo` when deciding senpi-side behaviour, and nothing in `~/.omo` knows about `~/.senpi`.

## Goal

Establish `~/.omo` as the omo-side source of truth that senpi **also** consults, so a user who only has `~/.omo` gets a working omo-native senpi without also hand-editing `~/.senpi`.

Depends on the user-config unification (see the companion issue in `code-yeongyu/oh-my-openagent`) — that one makes `~/.omo` the canonical config root; this one makes senpi read from it.

## Direction to evaluate

The senpi agent dir itself must stay `~/.senpi/agent` — it is upstream-fork branding (`AGENTS.md`: "Keep branding consistent: package `@code-yeongyu/senpi`, binary `senpi`, config directory `.senpi`") and moving it would break upstream mergeability and every existing install. So the unification must be **additive discovery**, not a relocation:

1. **omo-owned surfaces read `~/.omo` first.** Skills, rules, agents, teams, plans, and task/category config resolve from `~/.omo` with `~/.senpi/agent` as the senpi-native layer. Where both define the same key, document which wins.
2. **`~/.omo` may declare senpi overlay settings.** E.g. an `~/.omo/omo.jsonc` block that the `omo-senpi` extension translates into senpi runtime config at session start, so `~/.senpi/agent/settings.json` does not have to be hand-maintained for omo-driven behaviour.
3. **A user with only `~/.omo` is a supported state.** If `~/.senpi/agent` has no omo-specific configuration, everything omo needs is still resolvable.

## Open questions to answer before implementing

- Which senpi surfaces are safe to source from `~/.omo`? Skills and extensions are additive (`packages/coding-agent/src/core/skills.ts` already merges project + user + settings + CLI paths). `auth.json` and `sessions/` must remain senpi-only — never mirror credentials into `~/.omo`.
- Does adding `~/.omo` as a skills/extensions root belong in senpi core, or entirely inside the `omo-senpi` extension via the public extension API? The repo convention is extension-first; prefer the extension unless core cannot express it.
- How does this interact with `SENPI_CODING_AGENT_DIR`? A user pointing that at a sandbox must not accidentally pick up the real `~/.omo`, and the QA harness (`packages/omo-senpi/scripts/qa/drive.mjs`, which already isolates `XDG_CONFIG_HOME` for exactly this reason) needs an equivalent `~/.omo` isolation knob.
- Precedence when the same skill/rule/agent name exists in both roots.

## Scope of work

- [ ] Write down the intended layering (which root owns what, and precedence) in `packages/omo-senpi/AGENTS.md`.
- [ ] Implement `~/.omo` discovery in the `omo-senpi` extension for the surfaces deemed safe.
- [ ] Add an isolation env var so QA can point `~/.omo` at a sandbox; wire it through `packages/omo-senpi/scripts/qa/drive.mjs` and the e2e scripts that already isolate `XDG_CONFIG_HOME` and `SENPI_CODING_AGENT_DIR`.
- [ ] Extend `config-watch` to cover the additional roots without tripping the senpi protected-path rejection.
- [ ] Tests: only-`~/.omo` install works; only-`~/.senpi` install unchanged; both-present precedence is deterministic; sandboxed QA never touches the real `~/.omo` or `~/.senpi`.

## Non-goals

- Renaming or relocating `~/.senpi/agent`.
- Mirroring `auth.json`, `sessions/`, or `logs/` into `~/.omo`.
- Any destructive migration of existing user directories.