Exclude metadata informer compatibility test

[zhouguangyuan0718]

The deterministic compatibility log identified k8s.io/client-go/metadata/metadatainformer as the active package when the hosted runner terminated with exit 143 after more than five minutes in that compile.

This change:

• excludes that package and replaces it with k8s.io/client-go/transport/websocket
• keeps exactly 200 unique pinned packages
• lets a new release/rerun cancel an older lost run so the compatibility concurrency group cannot remain blocked

Validation:

• go test ./cmd/bent
• python3 -m unittest discover -s ci/llgo-compatibility -p "test_*.py"
• bash -n ci/llgo-compatibility/run.sh
• git diff --check

[fennoai]

Review summary

Scoped, low-risk change with three coordinated parts:

• cancel-in-progress: false → true in the compatibility workflow's concurrency block.
• Adds k8s.io/client-go/metadata/metadatainformer to the client_go exclude list in projects.toml.
• Regenerated benchmarks-llgo-compatibility.toml (the DO NOT EDIT generated manifest).

Correctness verified: the regenerated manifest is consistent with the exclude change — metadatainformer is absent, the 45 client_go entries shift up by one, transport/websocket is pulled in at client_go_045, and the total stays at 200 with no duplicate names/repos. The event_name segment of the concurrency group key structurally prevents a pull_request run from ever cancelling a trusted repository_dispatch release run, so there is no security concern with the cancellation change.

Two non-blocking items are noted inline. Nothing here blocks merge.

Worth confirming before merge: since the generator only checks eligibility (has tests, not main/cgo/etc.) and not baseline pass/fail, please confirm the newly-promoted client_go_045 = k8s.io/client-go/transport/websocket actually passes the Go baseline, so this swap doesn't trade one known failure for a fresh one.

[fennoai]

Both repository_dispatch types (llgo-tag-released and llgo-compatibility-rerun) collapse to the single 'release' fallback in the group key, and both share event_name = repository_dispatch. With cancel-in-progress: true, this means two legitimate back-to-back dispatches now cancel each other — e.g. a fresh tag release can abort an in-flight release for a different tag (a run with timeout-minutes: 180), and a rerun and a release can preempt one another. Because the publish step keys per-tag/commit, a cancelled run leaves a permanent gap in the compatibility history for that tag rather than just a delayed run.

This is safe with respect to PRs (the event_name segment keeps PR runs in a separate group, so fork PRs cannot cancel release runs) and matches the stated intent of freeing a stuck runner. But it is broader than the PR case. If preserving each legitimate release/rerun matters, consider making the group key release-specific by incorporating github.event.client_payload.llgo_tag || github.event.client_payload.llgo_commit (and/or github.event.action), so only redundant work for the same tag is cancelled. Otherwise, this is a reasonable trade-off worth confirming as a conscious decision.

[fennoai]

The shared comment above this exclude block states these packages "failed the Go baseline or LLGo dependency discovery in the first full hosted run." The new metadatainformer entry inherits that rationale by placement. Please confirm it actually hit one of those two failure modes (rather than, e.g., a runner-heavy/timeout reason like the ones documented separately for other projects); if the reason differs, update the comment so the stated rationale still describes every entry.