feat(portal): integrations feature (HeroUI migration)

[yashashkumar]

Why

The integrations feature existed only in app/web (Next.js + Mantine). This ports the entire integrations flow into apps/portal (TanStack Router + HeroUI) with the new dark/lime look, so portal reaches feature parity with web for integrations. The API contract and user flow are unchanged — only the UI framework and styling differ.

What

Integrations page (3-panel)

• Left rail — connector categories (Databases / KV / AI / BaaS / Observability), drives ?group=.
• Center — configured integrations for the selected group as an accordion; empty state prompts "Connect App/Service".
• Right — filter panel: search by name, filter by type, collapsible.

Connect / edit flow

• Group → variant cascade sourced from the server helpers (getIntegrationsGroups, getIntegrationsVariants, getDefaultVariantValue, getSchema, humanReadableConnectorNames) — single source of truth, no duplicated connector metadata.
• Dispatches to the right connector form:
  • CredentialsUrlForm — Postgres / MySQL / MongoDB / Redis / Memcached, with a Credentials|URL toggle and optional SSL / database fields.
  • AiForm — OpenAI / Anthropic / Gemini / Mistral, plus OpenAI-Compatible (base URL).
  • ObservabilityForm — Loki / OpenTelemetry Logs, with a Base64|Credentials toggle.
• AppConfigSelector — every config field accepts either a literal value or a cfg:<key> reference, backed by a searchable app-config key picker.
• Create / edit / delete / test-connection hit the same endpoints as web:
  • POST /v1/{projectId}/integrations
  • PUT /v1/{projectId}/integrations/{id}
  • DELETE /v1/{projectId}/integrations/{id}
  • GET /v1/{projectId}/integrations/list/{group}
  • GET /v1/{projectId}/integrations/{id}
  • POST /v1/{projectId}/integrations/test-connection
• Config is validated against getSchema(group, variant) before save.
• On edit, group + variant are locked (matching web).
• Deep-linkable via ?group= and ?open=.

Bug fix — server-into-browser bundle bleed

The integrations route crashed at load with:

The requested module '…__vite-browser-external:vm' does not provide an export named 'Script'

Root cause: the app-config DTO imported appConfigDataTypeEnum (a runtime value) from db/schema, which pulled the @fluxify/lib barrel → node:vm into the client bundle. Fixed by making the portal appConfig service's DTO imports type-only, so the whole chain is elided at build time. Also removed verbatimModuleSyntax from the portal tsconfig so the server integration schemas can be imported for reuse (adapters stay out of the bundle — verified via build).

Supporting UI

• Project shell / sidebar restyled to the mockup (gradient logo mark, FLUXIFY wordmark, lime active nav, "Back to projects").
• Design-token refinements: layered dark surfaces, lime accent, 12px radius, JetBrains Mono, softer focus halo, themed scrollbars, card polish.

Testing

Verified end-to-end in the browser against a running portal (:3001) + server (:5500), full CRUD round-trip with the network trace matching web:

• create → POST 201
• list refetch → GET list/{group} 200
• expand/edit → GET {id} 200
• delete → DELETE 204 → list refetch 200, no stray requests
• Test Connection, AppConfigSelector key lookup, group/variant cascade, and filters all exercised.

Typecheck (tsgo --noEmit) and vite build are clean.