docs: channel feature-parity principle + pool-parity/token-host follow-up plan

[nnemirovsky]

Why

Operating the credential-pool feature live exposed that pools are CLI-only — no /api/pools REST endpoints, no Telegram /pool commands — while every other store-backed surface (policy, credentials, bindings, MCP upstreams, default-verdict) is reachable from CLI + REST + Telegram. It also confirmed a real defect: pooled token-host phantom expansion rewrites every request to the shared OAuth token host, so a fresh in-container codex login --device-auth (device_code grant) is corrupted into 400 token_exchange_user_error.

What this PR adds (docs/plan only — no code)

• docs/plans/20260518-channel-feature-parity.md — follow-up implementation plan:
  1. Lift pool ops into a channel-agnostic internal/poolops package (root cause of the gap: rotate/status logic was written inline in cmd/sluice/pool.go).
  2. /api/pools REST endpoints, spec-first (api/openapi.yaml → make generate).
  3. Telegram /pool create|list|status|rotate|remove.
  4. Scope pool token-host phantom expansion to grant_type=refresh_token so non-refresh grants (device-code/auth-code) pass through untouched.
     Includes context, testing strategy, per-task checklists, and out-of-scope notes.
• CLAUDE.md / CONTRIBUTING.md — a general channel feature-parity principle: store-backed management features must land on CLI + REST + Telegram in the same PR via channel-agnostic logic; single-channel is allowed only with a documented rationale (e.g. local operator tools, CLI-stdin-only OAuth entry), otherwise reviewers should block the PR for parity.

Scope / notes

• Docs + plan only; no behavior change, so no release/tag (docs-only per the tag policy).
• The token-host grant-scoping is the v0.17.0 follow-up flagged in the v0.16.0 release notes' "Known limitation".
• Plan notes the synergy with the existing web-dashboard plan (it reuses internal/poolops once it exists).