feat(skills): invoke a user's own skill from a message

[andrii-novikov]

Applicable issues

• fixes Invoke user skills from a chat message (phase 1) #549

Description of changes

Lets a user invoke their own skill from a message, in a conversation with an agent they don't
own. Phase 1a of docs/designs/skill_invocation.md.

The client puts the picked skill on the user message; DIAL Core auto-shares it to the app's
per-request key (already done in epam/ai-dial-core#1956):

{
  "role": "user",
  "content": "/code-review focus on auth",
  "custom_content": { "skills": [{ "url": "skills/<bucket>/code-review" }] }
}

QuickApps resolves it, registers it as an ordinary skill, and injects a synthetic read_skill
call/result pair so the manifest is in the model's context before it answers — the model doesn't
get to decide whether to load it.

New package quickapp/skill_invocation/ (preview-gated, registered after DialSkillsModule):

File	Role
_skill_reference.py	Parses custom_content.skills[*] off user messages — canonicalises the URL, drops malformed entries, keys picks by user-message ordinal
_skill_invocation_initializer.py	Resolves every pick in the conversation through the existing DialSkillResolver
_invoked_skills_context.py	SkillsProvider at order = -10, display_name = "user skills"
_skill_invocation_injector.py	StagedToolSyntheticInjector subclass that injects the pair
_settings.py	SKILL_INVOCATION_MAX_SKILLS (default 10)

Because a pick becomes an ordinary SkillsProvider entry, everything downstream works unchanged:
the SkillsRegistry merge, generate_skills_xml, read_skill, and bundled-file reads via
DialSkillReader. quickapp/dial_skills/ is not touched.

Behaviour

• The pair goes after the first user message — the slot the built-in file-transfer skill already
  uses — and the user sees the normal "Reading Skill: <name>" stage.
• It is injected only on the turn the pick is made. Later turns restore it from
  state.tool_execution_history like any other tool result, so read_skill is never re-run and the
  model keeps the manifest it first saw.
• Picks stay registered on every turn, so a skill picked on turn 1 is still listed in
  <available_skills> and its bundled files still resolve on turn 4.
• A pick wins a name collision with one of the agent's skills; the agent's is dropped and
  reported by the existing SkillsRegistry collision path. Accepted for 1a — see Known gaps.
• A pick that can't be loaded gets a fixed error result naming the skill, and the reason is shown to
  the user. The request is still served.
• custom_content.skills is stripped from the working messages by a transformer in the
  never-preview-gated SkillsModule, so the field cannot reach the orchestrator deployment or a
  DIAL deployment tool even with the feature off.

Outside the feature package

• StagedToolSyntheticInjector.stage_level becomes an overridable class attribute, defaulting to
  the StageDisplayLevel.DEBUG it previously hardcoded — every existing subclass is unaffected.
  Skill invocation raises it to INFO, because the user asked for the skill explicitly.
• REQUEST_MESSAGES DI alias, so an initializer can read the raw request messages (they run before
  setup_messages populates context.messages).

Deviations from the approved design — the design doc is a historical record and was not edited,
so recording them here:

Design says	Implemented as	Why
A pair per distinct chip, own multi-call injector, three synthetic_injection helpers made public	One skill per message, stock StagedToolSyntheticInjector on APPEND_IF_CHANGED	Reuses the existing injector instead of duplicating its tool lookup and arun call; common/synthetic_injection/synthetic_tool_call_injector.py ends up untouched
Pair inserted after the message that picked the skill	After the first user message	Consistent with every other skill injection
Extra chips undefined	Ignored, reported as a warning-severity initialization issue naming them	A client bug should be visible, not silent

Docs: docs/skills.md gains an "Invoking a Skill from a Message" section; README.md documents
SKILL_INVOCATION_MAX_SKILLS; CLAUDE.md notes the new package.

Known gaps (documented, deliberate for 1a)

• A pick shadows an agent skill of the same name for the conversation. Phase 1b gives picks
  collision-free names.
• A skill picked on turn 3+ is not persisted, so it's in the model's context for that turn only. It
  stays listed and read_skill-able, just not re-injected. Turn-1 picks — the realistic
  "/code-review … opens a task" flow — are fully stable.
• A skill shared with the user and later unshared makes DIAL Core reject every later turn with
  403, before the request reaches QuickApps. Fix belongs in Core.
• An edited skill can leave two manifests in context. _inject_append_if_changed matches an existing
  pair on content as well as tool and arguments, so when the user edits the skill in Core between
  turns the match fails and a second pair is appended instead of replacing the first. The flaw is in
  the shared SyntheticToolCallInjector — _InjectFileTransferInstructionTransformer has the same
  exposure, only a redeploy is needed to reach it — and skill invocation makes it reachable by an
  ordinary user action. Either fix changes behaviour for every injector, so it is out of scope here.

Testing: 44 new unit tests (skill_invocation_tests/, plus the scrub transformer and the
stage_level override). make lint clean, make test 2052 passing. Integration tests not run.

Not in this PR: the ai-dial-chat side (the / palette, skills on MessageCustomContentDto)
is agreed but not started, so the feature is unreachable from the UI until that lands.

Checklist

• Title of the pull request follows Conventional Commits specification
• Design documented is updated/created and approved by the team (if applicable)
• Documentation is updated/created (if applicable)
• Changes are tested on review environment
• App schema changes are backward compatible, or breaking changes are documented with a migration guide
• Integration tests pass

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.