Re-append kimik2.5-int4-b300-vllm changelog entry

[functionstackx]

Summary

Re-appends the kimik2.5-int4-b300-vllm changelog entry at the bottom of perf-changelog.yaml. The entry is identical to the one merged in #1267.

The auto-merge of #1267 was performed by GitHub's internal web-flow user, and per GitHub Actions' documented security policy, push events created by GITHUB_TOKEN do not trigger downstream workflows. As a result, run-sweep.yml did not fire for the merge commit (9c7fb6f3) and no benchmark sweep ran for the new config. This duplicate entry produces a fresh diff against perf-changelog.yaml so process_changelog.py picks the config back up and the sweep runs.

🤖 Generated with Claude Code

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://cookbook.sglang.io/
• https://docs.vllm.ai/projects/recipes/en/latest/

If it is not, please create a PR first before we can merge your PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sgl-cookbook

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[claude]

LGTM — mechanical re-append of an existing changelog entry to retrigger the sweep workflow that GITHUB_TOKEN-driven auto-merge skipped.

Extended reasoning...

Overview

This PR appends 9 lines to the bottom of perf-changelog.yaml — a duplicate of the kimik2.5-int4-b300-vllm entry already merged in #1267 (and referencing the same originating PR #1057). The added block is byte-identical to the existing entry near line 2125 of the file.

Security risks

None. The change is a YAML data-only edit to a changelog file with no executable code, no secrets, no permissions surface, and no auth-relevant behavior.

Level of scrutiny

Low. The change is mechanical, self-contained, and the rationale is clearly documented in the PR description: GitHub Actions does not fire downstream workflows for pushes created by GITHUB_TOKEN (which is what auto-merge used for #1267), so run-sweep.yml did not trigger and no benchmark ran. Re-appending the entry produces a fresh diff so process_changelog.py picks the config back up.

Other factors

The bug hunting system found no issues. There are no outstanding reviewer comments other than the standard github-actions[bot] recipe-reminder template that is posted on every PR. The PR touches only a single file with no logic changes, and a duplicate-entry approach is the conventional workaround for this GitHub Actions limitation.