feat(flows): community flows — publish / browse / import (core)

[nbkdoesntknowcoding]

The core client for Community Flows — a shared central catalog every Mnema instance (cloud + self-hosted) can browse and import flows from. One hub, many instances (the n8n-community-templates model).

This is the public/core port of the feature; the private full version (core + the EE hub) lands in the source-of-truth repo separately.

What ships here (core)

• routes/community.ts — browse / import / publish client
• lib/community/ (hub-client, hub-config) + lib/flows/portability.ts + template-schema.ts — on publish, sanitize (drop doc_id/docs/target_folder_id); on import, rehydrate as unbound "needs binding" nodes. No source-workspace content ever travels.
• validate.ts draft mode tolerates imported-but-unbound nodes; publish re-validates strict
• web: /app/community browse + detail, Settings → Community, publish from the flow header; COMMUNITY_HUB_URL/_ENABLED/_KEY env
• schema: the flow community slug + the (self-host-inert) hub tables; migrations 0071/0072
• auth: bypass the session gate for /api/hub/* (served by the hub overlay when present)

Open-core boundary

The EE hub + moderation routes (community-flows-hub.ts, admin/community.ts, registered from the absent ee/index.ts) are intentionally excluded — a self-hosted instance never runs a hub, it points at one. The hub tables stay in the shared schema as inert empty tables (same convention as meetings/graph).

Verification

• Assembled onto latest main; new files copied, shared changes applied by context onto mnema's carved files; the 2 EE routes + ee/index.ts excluded.
• No dangling imports to EE files; every community.ts dependency resolves in core.
• Authoritative build check: the core-only + Lint/typecheck/tests CI on this PR.

Checklist

• Signed off for the DCO.
• Core change — EE hub excluded.