feat(ai-tools): greek-room repeated-words endpoint + fluent-ai client

[JEdward7777]

Summary

Exposes fluent-ai's Greek-Room Repeated Words check through fluent-api as the first AI-tool endpoint, behind a generic, reusable pattern designed to absorb future AI tools (other Greek-Room checks, LLM drafting, embeddings) with a small per-tool wrapper.

This is the implementation that follows the design reviewed and approved in PR #173 (kaseywright, 2026-06-02). PR #173 was documentation/proposal only and has been merged; this PR contains the actual code on a fresh branch (jel-word-check-impl), rebased on top of current main.

⚠️ Prerequisite — paired fluent-platform PR

This PR is paired with a small fluent-platform compose PR that must land for the live fluent-api ↔ fluent-ai connection to authenticate and for the integration to run from a clean stack:

Prerequisite: eten-tech-foundation/fluent-platform#5

Without those compose overrides, fluent-api cannot reach/authenticate against fluent-ai (and the ai container fails to come up from a clean slate), so an end-to-end run / any future integration check would fail. The fluent-platform PR adds FLUENT_AI_URL: http://ai:8200, mounts fluent-api/scripts into the api container, and fixes two clean-slate ai-container issues (MIGRATIONS_DATABASE_URL password drift and a UV_CACHE_DIR on a noexec mount).

What's added

New endpoint: POST /ai/tools/greek-room/repeated-words

• Introduces /ai/ as fluent-api's first service-family prefix. Per-tool URL preserves OpenAPI type-safety (a generic /dispatch was rejected).
• Guarded by BetterAuth session + requirePermission(PERMISSIONS.AI_TOOLS_USE).
• Envelope pass-through (D9): forwards fluent-ai's ToolJobResponse<T> verbatim — 200 for terminal statuses, 202 for non-terminal (queued/running) — so the same code path handles sync today and polling later.
• No request enrichment (D8): body forwarded verbatim (intentional snake_case field names, with an in-code guardrail comment).

Shared client: callFluentAi<TReq, TResult>(toolPath, body, schema, options?) in src/lib/services/fluent-ai/

• Modeled on the existing Mailgun service + withDatabaseRetry patterns. Adding a new tool is ~2 files / a few lines.
• Builds the target URL from FLUENT_AI_URL + optional FLUENT_AI_API_PREFIX + toolPath; 30s default timeout; validates result against the schema only when status === "completed".
• Maps transport/HTTP/parse failures → AI_SERVICE_UNAVAILABLE; failed/cancelled envelopes → AI_TOOL_EXECUTION_FAILED (both → HTTP 502). No polling, caching, or retries by design.

Configuration:

• New required env vars FLUENT_AI_URL, FLUENT_AI_KEY (no defaults — boot fails if missing), plus optional FLUENT_AI_API_PREFIX (defaults to empty to match the live fluent-ai build, which serves routes at the root; set /api/v1 when fluent-ai versions its routes). Documented in .env.example, test values in .env.test.
• PERMISSIONS.AI_TOOLS_USE as a string alias of content:update (D10).

Tests & tooling:

• fluent-ai.client.test.ts — completed/queued happy paths, failed/cancelled and 4xx/5xx/network/parse/schema/timeout/abort error mappings, request-shape assertions, and FLUENT_AI_API_PREFIX cases.
• ai-tools.route.test.ts — 401/403/400, 200 completed pass-through, 202 queued pass-through, 502 on failure, and a "no enrichment" verbatim-forward assertion.
• scripts/smoke-repeated-words.ts + npm run smoke:repeated-words — host/in-container probe with BetterAuth auto sign-in and a PASS/FAIL banner.

Verification

• ✅ Full quality gate green (pre-push hook): prettier --check, eslint, tsc --noEmit, and 78/78 vitest tests passing.
• ✅ Live end-to-end smoke test: 10/10 checks, HTTP 200, run against the running fluent-platform stack (host → fluent-api → fluent-ai). Verified by container logs (POST /ai/tools/greek-room/repeated-words 200 on api; matching 200 on ai). The canned 3-verse corpus returns exactly two findings — one suspicious ("in in") and one legitimate ("truly truly") — with verse_count === 3.

Out of scope (deferred by design)

Polling endpoint (GET /ai/tools/jobs/{job_id}), DB persistence of tool runs, frontend hooks/UI, transport retries, caching, rate limits, MCP facade. The callFluentAi / ToolJobResponse shapes are forward-compatible with all of these.

See docs/proposals/repeated-word-check/ for the full design (Part 1/Part 2), the file-by-file implementation status, and the reviewer-orientation summary.