Issue for this PR

Closes #29727
Closes #21793

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

• Filter /skills list by permissions: The app.skills HTTP endpoint now calls skill.available(defaultAgent) instead of skill.all(), so the /skills slash command only shows skills the current agent is allowed to use.

• Hide the skill tool when globally disabled: ToolRegistry.tools() now checks Permission.disabled(["skill"], ...) and excludes the skill tool entirely when skill: "deny" or skill: { "*": "deny" } is configured, preventing the model from seeing or calling it.

• Check permission before loading skill content: In the skill tool executor, ctx.ask() now runs before skill.require(). This ensures the permission gate is evaluated before reading the skill from the in-memory store.

How did you verify your code works?

• Tested with a simple config that has the following permissions object

  "permission": {
    "skill": {
      "manager": "deny",
      "tester-*": "deny"
    }
  }

Now the skill doesnt show up in the registry, the model doesnt have knowledge of the skill from initial prompt, even when forced to use that skill, it gets denyed use of the skill.

Screenshots / recordings

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

One caveat: The /skills HTTP endpoint uses the default agent, not the currently active session agent, because the endpoint is instance-level and doesn't receive agent/session context. So if you switch to a subagent with stricter skill permissions, the /skills dialog might still show skills allowed for the default agent. But when that subagent actually runs, its own permissions will filter the tool description and block execution.