feat: Use skills in chat, part 4, Issue #7009

[hhharmEpm]

Description of changes

• support new feature flag from core - skills are shown only if deployment support them
• add invalid ChatSkill state

- remove description workaround and take description from listing request

Applicable issues

• fixes [AI DIAL Chat Next Generation] Support skills usage #7009

UI changes

<Please, provide Screenshots or Figma links>

Checklist

• the pull request name ends with (Issue #<ISSUE_ID>) (comma-separated list of issues)
• I confirm that I don't share any confidential information like API keys or any other secrets and private URLs

PR title cheatsheet

<type>[optional scope]: <description>

1. type (required)
   • feat - A new feature
   • fix - A bug fix
   • docs - Documentation only changes
   • test - Adding missing tests or correcting existing tests
   • ci - Changes to our CI configuration files and scripts
   • chore - Other changes that are minor and/or not user-facing
2. scope (optional, current repo suggestions below)
   • chat
   • overlay
   • shared
   • sandbox-overlay
   • visualizer-connector

[github-actions]

✅ security-review: No blocking security issues. Trusted-backend string forwarding, UI-only skill gate (correct scope), React-escaped rendering, and removal of per-skill file-download N+1 all look safe.

Severity	Location	Message
info	apps/chat-api/src/skills/utils/skill-metadata.util.ts:46	Description is forwarded from DIAL Core's attributes.description with no length cap. Because DIAL Core is a trusted internal upstream (not user-controlled input), there is no injection risk; however, an unusually large value would reach the client verbatim. Not a vulnerability, but worth noting if DIAL Core ever exposes user-authored content through this field. Suggested fix: Optional: add a server-side MAX_LENGTH guard (e.g. 4096 chars) in the mapper if upstream provenance ever becomes less trusted.
info	apps/chat/src/components/ConversationView/ConversationView.tsx:1061	isSkillUnsupported / isSkillsSupported is a UI-only gate — it disables the send button client-side but does not block a raw API call that includes custom_content.skills. This is the correct scope for a UX constraint; DIAL Core is expected to enforce the feature boundary on its own message-handling path. Document this as a UX guard, not a security boundary, if not already clear in internal docs.

Run details

[github-actions]

⚠️ code-review: Approve: skills-listing descriptions replace the per-hover manifest fetch (N+1 removed, ~200 lines simplified) and skills_supported gating. Only cosmetic nits; no blocking issues.

Review: Use skills in chat, part 4 — approve

• Drops the lazy skill-description N+1 (per-hover manifest fetch + cache layer) now that DIAL Core listings carry description (Core PR fix(chat): Error messages appear for Admin are impossible to read (Issue #1944, #1959) #1970).
• Surfaces skills_supported from Core deployments and gates skill-selection entry points; already-selected chips render an error state on unsupported deployments.
• Host-agnostic: lib takes a plain isSkillsSupported boolean; deployment/Core knowledge stays in the app.
• No blocking findings; two info-severity notes (deploy-load unsupported-state flash; tooltip intentionally drops 'View details' in unsupported branch).
• Sandbox prevented running nx test/lint; in-diff specs are behavior-focused. Confirm npm exec nx test chat-api and npm run validate:docs are green before merge.

Run details