setup-wayfinderlisted

# Setup claude-wayfinder Materialize the Python venv at `${CLAUDE_PLUGIN_DATA}/venv/` so plugin hooks can spawn a Python that has `claude_wayfinder` importable. Write the setup-state flag so hooks know setup completed. The behavior described below is mirrored by `tests/integration/setup_pipeline.py`. If you change anything here, update that file too (CI's `test_skill_pipeline_sync.py` enforces this). ## Step 1: Resolve `${CLAUDE_PLUGIN_DATA}` The plugin data directory path is keyed `<plugin>-<marketplace>` by the harness, and the **same plugin resolves under different marketplace keys across surfaces** — `claude-wayfinder-glitchwerks` on a CLI surface, `claude-wayfinder-inline` on a desktop/ccd surface. Two sources are available, in priority order: - **Runtime env var** `$CLAUDE_PLUGIN_DATA` (no braces) — the test seam, but the harness sets it to whichever plugin invoked the current surface, so **another plugin's data dir can leak in** (e.g. `codex-inline`). Honor it **only when its basename is a same-plugin key**: `claude-wayfinder-<marketplace>` with exactly **one** marketplace segment after the plugin name (`-glitchwerks`, `-inline`, …). This admits every marketplace variant while rejecting two leak classes — unrelated plugins (`codex-inline`) **and prefix-colliding sibling plugins** whose own name starts with `claude-wayfinder-` (e.g. `claude-wayfinder-helper` → key `claude-wayfinder-helper-inline`, which has a second `-` segment). Do **not** require an exact `-glitc