Add Polymarket, Kalshi, and Hyperliquid trading integrations

[ElioNeto]

Issue imported from tinyhumansai/openhuman#1398
Created at: unknown

---

Summary

Add explicit trading / market integration tools for Polymarket, Kalshi, and Hyperliquid so OpenHuman can perform market-aware crypto workflows through supported external venues instead of only raw wallet actions.

Problem / Context

Wallet access alone is not enough for the product direction implied by the current ConnectionsPanel and capability surfaces. Users will also expect the agent to interact with specific trading and prediction-market venues.

The repo currently has:

• A general built-in integrations_agent aimed at Composio-backed SaaS toolkits.
• No exchange / prediction-market domain in the Rust core.
• No tool surface for venue-specific auth, balances, positions, orders, market discovery, or settlement workflows.

Polymarket, Kalshi, and Hyperliquid each carry different auth, market-model, and execution semantics, so they should be scoped explicitly rather than folded into vague “exchange support”.

This task should attach to umbrella issue tinyhumansai#1394.

Scope (optional)

In scope:

• Define the integration architecture for Polymarket, Kalshi, and Hyperliquid.
• Add the minimum tool / controller surfaces for account status, balances, positions, market lookup, and order placement/cancellation where allowed.
• Align the UX entry points with app/src/components/settings/panels/ConnectionsPanel.tsx and capability-catalog messaging.
• Add test/mocking strategy for venue-specific APIs and failure paths.

Out of scope:

• Generic wallet send/swap/contract tools that are not venue-specific.
• A broad broker / exchange abstraction covering every future provider.
• Autonomous continuous trading loops unless separately specified.

Implementation notes:

• Be explicit about what is wallet-signed vs API-key / venue-authenticated.
• Keep provider-specific behavior in dedicated modules; avoid a monolithic “crypto exchange” blob.
• Where possible, reuse existing integration / agent patterns, but do not force these venues through Composio if that weakens type safety or execution clarity.

Acceptance criteria

• Venue architecture defined — Polymarket, Kalshi, and Hyperliquid each have a clear integration seam in the app/core architecture and issue-level implementation plan.
• Tool surface added — account, balance, position, market, and order actions are exposed through explicit controllers / tools for supported venues.
• Connection UX wired — Settings connections and capability-catalog surfaces reflect the real supported trading venues instead of generic coming-soon placeholders.
• Failure-path design — auth failures, market lookup failures, rejected orders, and rate limits have deterministic handling and test coverage.
• Agent compatibility — the resulting tools are usable by the dedicated crypto/trading agent without broadening its permissions unnecessarily.
• Diff coverage ≥ 80% — the implementing PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/coverage.yml) when code changes are involved.

Related

• Parent: Add crypto wallet and trading workflows to the OpenHuman agent tinyhumansai/openhuman#1394
• Depends on: Add a dedicated crypto transaction agent tinyhumansai/openhuman#1397
• app/src/components/settings/panels/ConnectionsPanel.tsx
• src/openhuman/about_app/catalog.rs
• src/openhuman/agent/agents/integrations_agent/