Return 404 from Orbit skills routes for users without enabled namespaces

What does this MR do and why?

The Orbit skills routes now return 404 when the current user has no Orbit-enabled namespaces. Before, they only did that when the knowledge graph service wasn't configured. Users without access now get the local-only skill from the CLI, which already falls back to the embedded skill on 404.

References

• Issue: gitlab-org/orbit/knowledge-graph#1357 (closed)
• Follow-up to !259634 (merged)
• CLI fallback: gitlab-org/orbit/knowledge-graph!2703 (merged)

Screenshots or screen recordings

Not applicable, this is a backend/API change only.

How to set up and validate locally

1. Run the request specs:

   bundle exec rspec ee/spec/requests/api/orbit/data_skills_spec.rb

2. In GDK, with the knowledge graph service configured, call the skills route as a user who has Reporter or higher on a group with an Orbit-enabled namespace. It returns 200:

   curl --header "PRIVATE-TOKEN: <token>" "http://gdk.test:3000/api/v4/orbit/skills"

3. Call the same route with a token for a user who has no Orbit-enabled namespaces. It returns 404 with Skills are not available.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Agent context

require_skills_available! in ee/lib/api/orbit/data.rb now also calls AuthorizationContext.for(current_user).has_enabled_namespaces?, the same check the other Orbit endpoints use. It's memoized per request, and admins short-circuit to true. The skills routes keep skipping the entitlement check, so unlicensed users get 404 rather than 403.