feat(coexistence): factory should detect and document interop with existing agent frameworks (BMAD, kos, etc.) instead of plowing through

## Summary

Many target projects already use an agent / planning framework other than vsdd-factory: BMAD-method (with `_bmad/`, `_bmad-custom/`, `_bmad-output/` directories), kos process (with `_kos/` and a charter renderer), Linear+manual triage, or homegrown workflows.

vsdd-factory currently has no detection / acknowledgement / coexistence story. The skills run as if vsdd-factory is the only framework in the project. This creates:

- Confused operators ("do I follow BMAD's PRD process or vsdd-factory's create-prd?")
- Duplicate artifacts (BMAD-output PRD + vsdd-factory PRD living side by side)
- Process collisions (`/bmad-bmm-create-prd` vs `/vsdd-factory:create-prd`)
- No guidance on which is authoritative

## Repro on switchboard-blue (2026-06-23)

```
$ ls
_bmad/ _bmad-custom/ _bmad-output/ _kos/ .factory/ ...
```

The project has full BMAD scaffolding, a kos process described in `CLAUDE.md`, AND vsdd-factory's `.factory/` worktree from this session. No skill in vsdd-factory acknowledged the existence of `_bmad/` or `_kos/` or asked how they should coexist.

## Proposed

### Detection skill / preflight

Add to `/vsdd-factory:factory-health` (or as a new `/vsdd-factory:framework-coexistence` skill):

```bash
detect_other_frameworks() {
test -d _bmad && echo "BMAD detected: _bmad/"
test -d _bmad-custom && echo "BMAD custom agents: _bmad-custom/"
test -d _bmad-output && echo "BMAD output: _bmad-output/"
test -d _kos && echo "kos process detected: _kos/"
test -f charter.md && echo "kos charter present: charter.md"
grep -ril "bmad" CLAUDE.md 2>/dev/null && echo "CLAUDE.md references BMAD"
grep -ril "kos" CLAUDE.md 2>/dev/null && echo "CLAUDE.md references kos process"
}
```

### Coexistence guidance

When another framework is detected, surface guidance during onboarding:

```
⚠️ Other agent frameworks detected:
- BMAD (_bmad/, _bmad-custom/, _bmad-output/)
- kos (_kos/, charter.md)

Recommended posture:
- vsdd-factory provides the verified-spec-driven pipeline (Phase 3 TDD,
Phase 5 hardening, holdout eval). BMAD and kos provide upstream brief /
spec / discovery. They are complementary, not redundant.
- The vsdd-factory L2 Domain Spec and L3 PRD can be derived from a BMAD
PRD-equivalent in _bmad-output/. Run `/vsdd-factory:import-brief` to
convert BMAD output → vsdd-factory product-brief.md.
- kos findings / nodes can be referenced from vsdd-factory's adversarial
review context. Configure in .factory/repo-config.yaml:
external_evidence:
kos: _kos/findings/
bmad: _bmad-output/

If you intend to STOP using BMAD/kos and adopt vsdd-factory exclusively,
say so and the orchestrator will help you migrate.

If you intend to keep BOTH active, run /vsdd-factory:coexistence-config.
```

### Coexistence config file

`.factory/coexistence.yaml`:

```yaml
detected_frameworks:
bmad:
path: _bmad/
output_path: _bmad-output/
authoritative_for: [brief, prd] # or [] if migrated out
feed_into: [vsdd-factory.spec_phase]
kos:
path: _kos/
authoritative_for: [discovery, exploration]
feed_into: [vsdd-factory.adversarial_review]
```

## Acceptance criteria

- [ ] Factory-health detects `_bmad/`, `_bmad-custom/`, `_bmad-output/`, `_kos/`, `charter.md` and other common agent-framework markers.
- [ ] When detected, the skill surfaces coexistence guidance (not just a warning).
- [ ] A `.factory/coexistence.yaml` records the operator's intent (migrate / keep both / unknown).
- [ ] Downstream skills (create-brief, create-prd, adversarial-review) read coexistence.yaml and route around the operator's decision.
- [ ] Documentation page in `docs/guide/` covers BMAD ⇔ vsdd-factory and kos ⇔ vsdd-factory interop patterns.

## Found during

Setting up vsdd-factory on `switchboard-blue` (2026-06-23, vsdd-factory@1.0.0-rc.21). The project uses kos (described in `CLAUDE.md`, with `_kos/nodes/bedrock/`, `_kos/frontier/`, `charter.md`, and a documented "Session Protocol") AND BMAD (`_bmad/`, `_bmad-custom/`, `_bmad-output/`). vsdd-factory plowed through `/onboard-observability` + `/factory-health` + `/setup-env` without acknowledging either.