Use label permissions for label UI checks

What does this MR do and why?

Views and helpers that show label controls still checked admin_label. This MR moves those checks to the specific label permissions, so the UI asks the same question as the controllers and API. Nobody gains or loses access, so the same roles see the same controls.

• "New label" buttons, empty states and the board label dropdown check create_label.
• The priority star, prioritized label drag and the priority empty state check update_label. The promote option checks promote_label on the group. The label actions dropdown checks update_label.
• work_items_helper and the issuable sidebar entity back their can_admin_label values with create_label. Their keys are renamed to can_create_label to match. Both only decide whether to show a "Create label" button.

The label actions dropdown always shows edit and delete together. That is fine today because every role that can update a label can also delete it. Splitting it needs a frontend change and is out of scope here.

No changelog, since user-facing behavior does not change.

References

• Related to #566177
• Depends on !257922 (merged)

Screenshots or screen recordings

No UI change. The same roles see the same controls.

How to set up and validate locally

bundle exec rspec spec/helpers/boards_helper_spec.rb ee/spec/helpers/ee/boards_helper_spec.rb spec/helpers/work_items_helper_spec.rb spec/helpers/issuables_helper_spec.rb spec/serializers/issue_sidebar_basic_entity_spec.rb spec/features/projects/labels spec/features/groups/labels

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.