Add eget rule linting for /eget entries in src/ yml

[edwinjhlee]

Background

Many yml entries under src/ declare a /eget rule that resolves to a GitHub repo via x eget resolve <owner>/<repo>. Today validation is manual — contributors run the command themselves, and there's no automated check that:

• the <owner>/<repo> exists
• the repo publishes releases with downloadable assets
• the asset naming convention matches what x eget expects (or auto-resolves)

This means a contributor can merge a yml with a broken /eget rule and only find out when someone runs x install <pkg>.

Goal

Add a lint step (in the build-data workflow or as a separate workflow) that:

1. Walks src/**/*.yml
2. For each yml with a /eget rule, invokes x eget resolve <owner>/<repo> (or equivalent)
3. Reports failures clearly — either as workflow annotations or as a separate eget-lint report
4. Optionally fails the build on broken rules, or warns only

Non-goals

• This is not blocking current merges — happy path works
• Not changing the yml schema
• Not validating non-eget rules (apt/brew/pip/etc. trust their references as-is for now)

Why separate from build-data

build-data rebuilds all.tsv + all.tar.xz. Linting eget rules is orthogonal — it can run on PR, on schedule, or as a standalone job. Want to design its frequency and failure semantics carefully before wiring it in.

Open questions

• Should eget-lint block merge on PRs, or warn only?
• Run on every push, on schedule, or both?
• Surface results as PR check, GH Actions summary, or both?

cc: @x-cmd-install/maintainers