Per-member skill learning control and skill provenance fix

[helpcodeai]

Summary

Two things around workspace skills, see #1145.

1. Generating skills deleted every pending skill in its scope, so a skill filed by the Agent Skills Finder and waiting for approval was gone after the next "Generate" (manual pending skills too). Skills now record where they came from and generation only replaces its own pending AI suggestions.
2. Intent capture was a single switch for the whole workspace. Admins can now decide per member whether their requests feed skill learning, and every member can opt out. In many companies this has to be decided per person (data protection, works council agreements), so it needs to be explicit and logged.

Changes

• kg_skill_suggestions.source (manual, llm, finder), backfilled from existing rows (Finder skills by their "Source: … (licence: …)" line, LLM ones by confidence < 1). generate deletes only source: 'llm' pending rows; consolidated skills are tagged llm; skills_save_to_workspace files finder.
• activeSkillsText takes and filters by organizationId. The shared /mcp guide reads each workspace's skills with its own org and only its own server/connector ids.
• class-validator DTOs for the skill endpoints (create, update, generate, consolidate).
• organization_members.learning_mode (inherit default, on, off) and learning_opt_out. Effective rule: not opted out, and on, or inherit with the workspace "Capture user intent" switch on. Existing workspaces behave exactly as before.
• KgLearningService + endpoints: GET/PUT /api/knowledge-graph/learning/me (any member, opt-out and optional erase of own intents) and PUT /api/knowledge-graph/learning/members (admin, up to 500 members, optional erase for members that end up off). Only members of the caller's workspace are touched.
• The MCP per-server endpoint checks the caller, not just the workspace: only contributing members get _intent. Callers without a member identity (static instance credentials, client-credentials tokens) or deactivated members never contribute.
• New security event LEARNING_CHANGED, one row per member.
• UI: Settings > Users gets a "Skill learning" column, row selection and a bulk bar with "erase captured requests when turning off". Settings > Profile gets a "Skill learning" card (status, opt-out, erase my captured requests). The organization toggle text says it is the default for members.
• Docs: docs/knowledge-graph.md explains who contributes and that generation keeps manual and Finder skills.

Cloud and self-hosted behave the same. Settings live on the membership, so one person in two Cloud workspaces can have different settings.

Type

• Bug fix
• New feature
• Documentation

Testing

• Added/updated unit tests
• Tested manually

Commands and results (after rebasing on main):

• npm ci (root): ok
• packages/backend: npx prisma generate, npx tsc --noEmit -p tsconfig.json: no errors
• packages/backend: npm run lint: 0 errors (existing warnings only); the files eslint --fix touched outside this change were reverted
• packages/backend: npx jest: 676 suites passed, 4 skipped; 20418 tests passed, 1496 skipped
• packages/frontend: npx tsc --noEmit -p tsconfig.json: no errors; npm run lint: 0 errors, no new warnings in the changed files
• root: node scripts/validate-adapters.mjs --warn: exit 0, existing warnings only (no adapter changes)
• Migration: npx prisma migrate deploy on an empty scratch database, then prisma migrate diff against schema.prisma: empty. The backfill regex was checked against Finder-style and manual instructions.

Manual end-to-end on a local backend (scratch database, MCP API key, OpenPLZ connector, tools/list over /mcp/:serverId):

State	Tools with _intent
Workspace switch off	0 of 6
Workspace switch on, member inherit	5 of 6 (all but kg_how_to_obtain)
Admin sets member off	0
Member inherit, opted out	0
Opt-out removed	5
Workspace switch off, admin sets member on	5

A tools/call with _intent stored the intent with the user id; setting the member off with clearIntents erased it (intentsCleared: 1) and the next call stored nothing. All six changes appeared as LEARNING_CHANGED security events. An invalid mode returns 400. Both new UI sections were checked in the browser.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• I have updated documentation (if applicable)
• All existing tests pass (backend npx jest; root npm test is not used because the frontend has no test script)
• This PR has a descriptive title

Related Issues

Fixes #1145

[helpcodeai]

Update after review (19 Oct): verified with a real model (gpt-4o-mini driving the MCP server as a chat client) and two independent security reviews. Fixes are in the PRs they belong to:

• Workspace skills v2: on-demand skills, procedures, versions and usage #1149: the skills_v2 migration now pins every server that receives applied skills today (its own or its connectors') to inline, so no existing server changes behaviour. On Cloud that is 13 servers.
• Folders for skills and company memory, with role limits #1154: folder references use NO ACTION (not cascade / set null), so a racing delete cannot move limited content to the top level.
• Learn skills from fixed errors, consolidate as proposals, link memory to the graph #1158: the remaining fixes (server-workspace scoping of per-server calls, explicit _intent request, any-word memory search, injection-like memory refused, error codes only in proposals, folder visibility for editors, call-time rechecks in stateful sessions, and more); see its description.

Merge the stack in order (#1146 → #1149 → #1152 → #1154 → #1158) and release them together.