Centralize auto-label mappings into a configuration file

[Sanketjadhav31]

Summary

PR that extracts the auto-label mappings into the configuration file makes maintenance and expansion of the mappings easier.

Changes

• Introduced .github/label-mappings.json that serves as the source of mappings between issue/pull-request labels.
• Updated the auto-labeling workflow to use the configuration file for mappings.
• Fixed missing mappings for [ebpf], [ubpf] and [graphs].
• Removed duplicate mappings by making them case-insensitive.
• Added documentation on how the configuration looks and how it can be extended.

Testing

• Verified that configuration is properly loaded.
• Confirmed that matching stays case-insensitive.
• Checked that all existing and newly introduced mappings work properly.

Fixes #5649

[chreekat]

Thanks for the PR!

As I just wrote in #5649, I don't think adding a configuration file is necessarily a good idea.

Furthermore, in this PR, you still duplicate the labels with the same inconsistencies that #5649 seeks to abolish.

I believe there is an idea worth pursuing here, so I encourage you to propose a different approach.

[Devansh-567]

Thanks for the PR!

As I just wrote in #5649, I don't think adding a configuration file is necessarily a good idea.

Furthermore, in this PR, you still duplicate the labels with the same inconsistencies that #5649 seeks to abolish.

I believe there is an idea worth pursuing here, so I encourage you to propose a different approach.

Thanks for the feedback, @chreekat.

I agree with the concerns about introducing a separate JSON configuration file. After reading your comments, I explored an alternative approach that keeps everything in JavaScript while separating the mapping data from the labeling logic.

The idea is to:

• Define shared mappings once to eliminate duplication and inconsistencies.
• Keep issue-specific and PR-specific mappings separate where their semantics differ.
• Make future mapping updates require changes only to the data section, not the workflow logic.
• Avoid introducing additional configuration parsing or files.

Please check #5660

[Sanketjadhav31]

Thank you for the comments, @chreekat.

I get your points on introducing a separate configuration file and on duplicating the mappings. I will revise my approach to keep all the things in JavaScript, declare the common mappings only once, and split the issue and PR mappings only where needed.

I will adjust this PR accordingly. Thank you for your guidance!