(CODUX-225) Extract the chat connector profile registry

[numnx]

🧩 Task: Extract the chat connector profile registry

Automated task PR opened by Code UX for T01.

📋 Summary

Sprint: Sprint 225 · Chat connector completeness and verification · Task: T01

Complete and verify all six chat connectors through provider-specific profiles, correct authentication and session behavior, encrypted durable state, atomic routing and retries, REST/MCP/dashboard management, official-documentation evidence, deterministic contract coverage, and credential-gated checks limited to provider-controlled endpoints, with Discord prioritized.

🤖 Model & Provider

Provider	Codex CLI
Model	gpt-5.6-sol

⏱️ Timing

Started	2026-07-13 22:29:34 UTC
Finished	2026-07-13 22:45:51 UTC
Duration	16m 18s

📊 Token Usage

Metric	Value
Input tokens	166,197
Cached input tokens	5,174,784
Output tokens	39,456
Total tokens	5,380,437
Invocations	1
Tool calls	46
Active time	15m 45s

Included usage estimate (subscription/local login): $4.60

✅ QA Review

⏳ QA review runs after this PR is opened. Check the task card in the dashboard for the outcome once it lands.

📝 Full Task Prompt

## Objective
Refactor the centralized chat-provider schemas, authentication hooks, normalization, outbound mapping, verification capabilities, and lifecycle metadata into a typed registry with one independently editable profile per supported connector.

## Scope
- `src/contracts/chat-provider-types.ts`
- Create `src/domain/chat-connectors/types.ts`, `src/domain/chat-connectors/registry.ts`, and `src/domain/chat-connectors/providers/{discord,whatsapp,telegram,slack,microsoft-teams,imessage}.ts`
- Refactor `src/services/chat-provider-security.ts`, `src/services/chat-provider-ingress-service.ts`, and `src/services/chat-provider-adapters.ts` into compatibility facades over the registry
- Create `tests/backend/domain/chat-connectors/registry.test.ts`
- Create baseline provider reference pages under `docs/settings/chat-connectors/` and `docs-web/architecture/chat-connectors/`, and link their indexes from `docs/index.md`, `docs/SUMMARY.md`, and `docs-web/architecture/index.md`

## Implementation Requirements
1. Define a `ChatConnectorProfile` contract covering setup schema, supported transport modes, ingress authentication and handshake behavior, inbound normalization, external conversation/thread identity, outbound request construction, verification strategy, session requirements, official documentation references, and live-test availability.
2. Add the additive `official_api` bridge mode without changing the persisted meaning of `managed_bridge`, `webhook`, or `native_bridge`; profiles must advertise only modes they actually implement.
3. Move each existing schema and provider normalizer into its provider module, statically register all six kinds, and keep compatibility exports such as `CHAT_PROVIDER_SETUP_SCHEMAS` and `getChatProviderSetupSchema` for current consumers.
4. Keep shared HTTP, redaction, timing-safe comparison, command execution, and validation helpers provider-neutral while ensuring provider modules can supply exact signature bases, headers, acknowledgements, retry metadata, and response parsing.
5. Add registry tests proving every `ChatProviderKind` resolves exactly once, legacy bridge modes retain their current schemas, unsupported kind/mode combinations fail closed, and registry construction performs no network or process side effects.
6. Seed provider-specific canonical and public Markdown pages so the parallel provider tasks can update separate files without touching shared indexes or generated docs-web artifacts.

## Constraints
- Preserve existing stored connection records and public response shapes unless a new field is additive and backward compatible.
- Do not implement provider network behavior in the registry itself or invoke live endpoints in unit tests.
- Do not require files from later provider tasks; each baseline profile must retain current bridge behavior until its owning task extends it.
- Keep secret values out of profile metadata, errors, logs, fixtures, and public schemas.

## Verification
- Run `pnpm run test:backend -- tests/backend/domain/chat-connectors/registry.test.ts tests/backend/services/chat-provider-ingress-service.test.ts tests/backend/services/chat-provider-outbound-service.test.ts`.
- Run `pnpm run lint` and `pnpm run build`.
- Run `pnpm run sync:docs-web` followed by `pnpm run check:docs-web`; all six provider pages and routes must be generated and linked.

🌿 Branch Info

Base: feature/CODUX-225-chat-connector-completeness-and-verification
Head: task/feature-codux-22-t01-codex-f29b0c11-mrjsorla

---

🤖 Generated by Code UX