Clarify managed Composio integration boundary

## Summary

- Clarifies in the root README that managed integrations are backend-proxied through OpenHuman's Composio connector layer.
- Updates the integrations docs to distinguish managed mode from direct Composio mode.
- Documents that direct mode needs the user's own Composio API key and separately hosted trigger webhook plumbing.

## Problem

- #2020 asks for clearer disclosure around cloud/backend and integration dependencies.
- The README advertised 118+ integrations with one-click OAuth, but did not state the managed Composio/backend boundary near that claim.
- The integrations page said users did not need to think about Composio, which is true for managed mode but incomplete for direct/BYO mode.

## Solution

- Add a short managed-vs-direct disclosure beside the README integrations bullet.
- Replace the vague Composio parenthetical in the integrations docs with explicit backend, OAuth, rate-limit, and webhook responsibilities.
- Add the direct-mode privacy-boundary change near the existing Privacy boundary section.

## Submission Checklist

- [x] Tests added or updated (happy path + at least one failure / edge case) per [Testing Strategy](../gitbooks/developing/testing-strategy.md#failure-path-requirement) — N/A: docs-only clarification.
- [x] **Diff coverage ≥ 80%** — N/A: docs-only change.
- [x] Coverage matrix updated — N/A: docs-only change.
- [x] All affected feature IDs from the matrix are listed in the PR description under `## Related`
- [x] No new external network dependencies introduced (mock backend used per [Testing Strategy](../gitbooks/developing/testing-strategy.md#mock-policy))
- [x] Manual smoke checklist updated if this touches release-cut surfaces — N/A: docs-only change.
- [x] Linked issue closed via `Closes #NNN` in the `## Related` section — N/A: #2020 is broader; this PR references it as a scoped docs follow-up.

## Impact

- Users evaluating OAuth/integration architecture get clearer docs before connecting accounts.
- No runtime behavior changes.

## Related

- Refs: #2020
- Follow-up PR(s)/TODOs: N/A
- Coverage matrix feature IDs: N/A: docs-only change.

---

## AI Authored PR Metadata (required for Codex/Linear PRs)

### Linear Issue
- Key: N/A
- URL: N/A

### Commit & Branch
- Branch: codex/2020-composio-disclosure-docs
- Commit SHA: 0d5a7ec2

### Validation Run
- [x] `pnpm --filter openhuman-app format:check` — N/A: docs-only change.
- [x] `pnpm typecheck` — N/A: docs-only change.
- [x] Focused tests: N/A: docs-only change.
- [x] Rust fmt/check (if changed): N/A: no Rust files changed.
- [x] Tauri fmt/check (if changed): N/A: no Tauri files changed.
- [x] `git diff --check`

### Validation Blocked
- `command:` N/A
- `error:` N/A
- `impact:` N/A

### Behavior Changes
- Intended behavior change: documentation now names the managed Composio/backend path and direct-mode responsibility split.
- User-visible effect: clearer README/GitBook disclosure for integration setup.

### Parity Contract
- Legacy behavior preserved: no code paths changed.
- Guard/fallback/dispatch parity checks: N/A.

### Duplicate / Superseded PR Handling
- Duplicate PR(s): N/A
- Canonical PR: N/A
- Resolution (closed/superseded/updated): N/A

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

## Summary by CodeRabbit

* **Documentation**
  * Clarified how Composio-backed integrations work in managed mode versus the new direct mode
  * Updated documentation to explain that managed mode handles OAuth, rate limits, and webhooks through the backend, while direct mode requires users to manage webhooks with their own Composio API key

<!-- review_stack_entry_start -->

[![Review Change Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/tinyhumansai/openhuman/pull/2325?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: aqilaziz <gonzes7@gmail.com>
Co-authored-by: Steven Enamakel <enamakel@tinyhumans.ai>

README.md

@@ -66,6 +66,8 @@ OpenHuman is an open-source agentic assistant designed to integrate with you in
 
 - **[118+ third-party integrations](https://tinyhumans.gitbook.io/openhuman/features/integrations) with [auto-fetch](https://tinyhumans.gitbook.io/openhuman/features/obsidian-wiki/auto-fetch)**: plug into Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira and the rest of your stack with **one-click OAuth**. Every connection is exposed to the agent as a typed tool, and every twenty minutes the core walks each active connection and pulls fresh data into the [memory tree](https://tinyhumans.gitbook.io/openhuman/features/integrations/auto-fetch). No prompts, no polling loops you have to write, so the agent already has tomorrow's context this morning.
 
+  Managed integrations are backend-proxied through OpenHuman's Composio connector layer. If you want to run Composio directly instead of using the managed backend path, configure direct mode with your own Composio API key; real-time trigger webhooks then need to be hosted and wired by you.
+
 - **[Memory Tree](https://tinyhumans.gitbook.io/openhuman/features/memory-tree) + [Obsidian Wiki](https://tinyhumans.gitbook.io/openhuman/features/obsidian-wiki)**: a local-first knowledge base built from your data and your activity. Everything you connect is canonicalized into ≤3k-token Markdown chunks, scored, and folded into hierarchical summary trees stored in **SQLite on your machine**. The same chunks land as `.md` files in an Obsidian-compatible vault you can open, browse and edit, inspired by Karpathy's [obsidian-wiki workflow](https://x.com/karpathy/status/2039805659525644595).
 
 - **Batteries included**: web search, a web-fetch [scraper](https://tinyhumans.gitbook.io/openhuman/features/native-tools), a full coder toolset (filesystem, git, lint, test, grep), and [native voice](https://tinyhumans.gitbook.io/openhuman/features/voice) (STT in, ElevenLabs TTS out, mascot lip-sync, live Google Meet agent) are wired in by default. [Model routing](https://tinyhumans.gitbook.io/openhuman/features/model-routing) sends each task to the right LLM (reasoning, fast, or vision) under one subscription. No "install a plugin to read files" friction. [Optional local AI via Ollama](https://tinyhumans.gitbook.io/openhuman/features/model-routing/local-ai) for on-device workloads.

gitbooks/features/integrations/README.md

@@ -7,9 +7,9 @@ icon: plug
 
 # Third-party Integrations (118+)
 
-OpenHuman ships with backend-proxied access to **118+ third-party services**. Connecting any of them is a one-click OAuth flow inside the app, there are no API keys to wire by hand, and no plugin marketplace to navigate.
+OpenHuman ships with backend-proxied access to **118+ third-party services**. Connecting any of them through the managed path is a one-click OAuth flow inside the app, there are no API keys to wire by hand, and no plugin marketplace to navigate.
 
-(Under the hood, the connector layer is powered by [Composio](https://composio.dev). You will not need to think about it.)
+Under the hood, the connector layer is powered by [Composio](https://composio.dev). In the default managed mode, OpenHuman's backend owns the Composio API key, OAuth token brokering, rate limits, and trigger webhook fan-out. If you switch to direct mode, the core talks to Composio with your own Composio API key; synchronous tool calls work, but real-time trigger webhooks must be configured on your own webhook infrastructure.
 
 Once a service is connected, it shows up in four places at once:
 
@@ -74,6 +74,8 @@ Two capabilities ship native rather than as integrations because they're load-be
 
 OpenHuman's core never calls any third-party API directly. All requests go through the OpenHuman backend, which handles OAuth tokens and rate limiting. Your tokens never sit on disk in plaintext on your machine, and the agent only sees the _results_ of tool calls, not the credentials.
 
+If you opt into direct Composio mode, that boundary changes: your local core uses your own Composio API key and you are responsible for the Composio account, rate limits, billing relationship, and any webhook endpoint needed for trigger delivery.
+
 See [Privacy & Security](../privacy-and-security.md) for the full boundary.
 
 ## See also