Inline User#runner_available? and simplify RunnerPolicy

What does this MR do and why?

This MR refactors runner ownership logic by consolidating authorization checks into Ci::RunnerPolicy and removing the workaround from the User model. The key changes include:

Policy Changes:

• Updates owned_runner condition in Ci::RunnerPolicy to use can?(:admin_runner) checks instead of runner_available?
• Adds new runner_available condition with optimized logic for project runners with multiple projects
• Separates ownership-based permissions from availability-based permissions

User Model Changes:

• Removes the workaround logic from User#runner_available? method that handled indirect group access
• Moves the explanatory comment about group runner limitations to ci_available_group_runners method
• Inlines the logic from runner_available? to only check if runner is in ci_available_runners

Authorization Logic:

• For instance runners (no owner): checks global :admin_runner permission
• For owned runners: checks :admin_runner permission on the runner's owner
• Maintains existing access patterns while making the code more explicit and maintainable

The refactoring improves:

• performance by limiting the use of the expensive ci_available_runners query
• code clarity by centralizing runner authorization logic in the policy layer and removing the temporary workaround that was handling indirect group access scenarios.

References

• Indirect maintainer permissions no longer suffi... (#502634 - closed)

Sample of changes to policy evaluation

Querying for :delete_runner on a project runner owned through an indirect project invitation

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.