Phase 5: group-voice docs, onboarding runbook, CHORUS icon — v2.0.0-rc.1

The final phase of CHORUS-PLAN.md. Code- and doc-complete for group use;
rc pends live deployment at chorusapi.mpm.to.

- Repo README rewritten for CHORUS: group model (schema 5), concurrency
  posture, configuration, baked-build onboarding, layout, testing, 2.0
  version history (ECHO history referenced at the fork tag).
- Operator→member voice sweep across SKILL.md (incl. the trigger
  description, now group-aware), all references, 8 command docs, plugin
  README; member preferences / semantic layer / triage guidance describe
  the group model.
- docs/ONBOARDING.md: member runbook — vault stand-up, per-member config,
  bake, deliver, self-onboarding first load, norms, offboarding.
- docs/USAGE.md rewritten as the member usage guide.
- New icon: chorus-icon.svg + 1024/512/64 PNGs (three voices, one center).
- Removed ECHO-era assets (icons, spec PDF, perf briefs); ECHO planning
  docs retired to docs/history/. All preserved at echo-fork-point.
- eval/README documents test_multimember.py. Manifest -> 2.0.0-rc.1;
  rebuilt chorus-memory.plugin.

Verified: routing-sync, 25/25 unit, scaffold, 5 mock e2e suites,
run_eval metrics green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

chorus-memory.plugin.src/README.md

@@ -2,7 +2,7 @@
 
 Persistent memory for Claude via the **CHORUS** Obsidian vault, using the [Obsidian Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api).
 
-Reads and writes notes across Claude/CoWork sessions through direct REST calls, routed through a bundled validated client (`scripts/chorus.py`) that status-checks every write. The toolchain is **pure Python**, so it runs identically on Windows, macOS, and Linux (only a Python 3 interpreter is needed — no bash). The plugin is **user-agnostic**: the vault owner, endpoint, and API key are not shipped in it — each machine supplies them through a local config file (see **Configuration**).
+Reads and writes notes across Claude/CoWork sessions through direct REST calls, routed through a bundled validated client (`scripts/chorus.py`) that status-checks every write. The toolchain is **pure Python**, so it runs identically on Windows, macOS, and Linux (only a Python 3 interpreter is needed — no bash). The plugin is **group-agnostic**: the group, member id, endpoint, and API key are not shipped in it — each machine supplies them through a local config file (see **Configuration**).
 
 Architected by **Jason Stedwell**.
 
@@ -10,7 +10,7 @@ Architected by **Jason Stedwell**.
 
 ## What it does
 
-- Loads operator preferences, current context, and relevant project notes at the start of substantive conversations
+- Loads the group profile, your member preferences, current context, and relevant project notes at the start of substantive conversations
 - **One-call `capture`** routes a memory to its canonical home, stamps **complete** frontmatter (kind-default `status`, kind-seeded `tags`), indexes it, auto-links any entity it mentions, and logs it — driven by a machine-maintained **entity index** so routing is an alias-aware lookup, not a fuzzy search. Updates keep the **whole body**; a title that strongly resembles an existing entity **stops at a duplicate gate** (exit 76 — `--merge-into <slug>` / `--force`) instead of spawning a near-duplicate
 - **`recall`** returns a topic's matching notes *and* their one-hop linked neighbourhood (Related links + `source_notes`) — the corpus spans the entity graph **plus session logs and journal notes** (down-weighted), ranked by BM25 × freshness × status so live notes outrank stale ones; **`resolve`** maps any mention to its canonical path; **`link`** adds reciprocal cross-links; **`triage`** routes aging inbox captures with an automatic processing-log audit trail
 - Logs working sessions so future conversations can pick up where they left off
@@ -83,7 +83,7 @@ skills/chorus-memory/
 │   └── session-log-template.md
 ├── scripts/                       ← pure Python; run with python3 (Windows: python / py -3)
 │   ├── chorus.py                    ← validated client + high-level CLI (capture/resolve/recall/link/load/scope/lock/config)
-│   ├── chorus_config.py             ← resolves owner/endpoint/key from the machine-local config (env-overridable)
+│   ├── chorus_config.py             ← resolves group/member/endpoint/key from the machine-local config (env-overridable)
 │   ├── chorus_index.py              ← entity index (registry, resolve, name→path map)
 │   ├── chorus_links.py              ← cross-link primitives (Related parsing, bidirectional linking)
 │   ├── chorus_ops.py                ← high-level ops (capture, recall, resolve, link, agent-log)
@@ -97,7 +97,7 @@ skills/chorus-memory/
 └── scaffold/                      ← verbatim files the bootstrap writes into the vault
     ├── README.vault.md  chorus-vault.md
     ├── templates/  (8 note templates)
-    └── anchors/    (operator-preferences, current-context, inbox seeds)
+    └── anchors/    (group-profile, group-inbox + member preferences/context/inbox seeds)
 ```
 
 ## Skills & commands
@@ -122,4 +122,4 @@ skills/chorus-memory/
 - **Python 3** available in the session environment (the scripts use only the standard library; invoke as `python3`, or `python` / `py -3` on Windows)
 - Obsidian running on the backend with the [Local REST API plugin](https://github.com/coddingtonbear/obsidian-local-rest-api) enabled
 - HTTPS access from the Claude/CoWork session environment to the endpoint configured in `~/.claude/chorus-memory/config.json`
-- A machine-local config (`~/.claude/chorus-memory/config.json`) supplying the vault owner, endpoint, and API key — see **Configuration**
+- A machine-local config (`~/.claude/chorus-memory/config.json`) supplying the group, member id, endpoint, and API key — see **Configuration**