[Proposal]: Establish binary size monitoring for Rslint

Rslint’s binary size is growing rapidly, while contributors and reviewers currently have no visibility into how much each pull request affects it.

Rspack monitors binary size by comparing pull requests against a baseline, reporting the difference, and retaining historical data from the main branch. Rslint could adopt a similar system, initially covering the stripped native executable.

Each pull request would show its binary size change against the base branch, and measurements from the main branch would be retained to show the long-term trend. This would give contributors and reviewers direct feedback on the binary size impact of their changes.

After @swwind reduced the install size by 10.95 MiB in v0.6.5 through #1168, it grew by 7.84 MiB (+23.26%) through v0.9.1.

For reference, Oxlint v1.81.0 is 17.41 MiB and oxlint-tsgolint v7.0.2001 is 21.26 MiB, totaling 38.67 MiB; Biome v2.5.12 is 61.43 MiB; Rslint v0.9.1 is 41.56 MiB (full installation size, Linux x64 glibc). Rslint’s rule coverage is still expanding, with many more rules expected to be ported in the foreseeable future, so we need to control binary size growth before it becomes increasingly difficult to manage.

I’d appreciate everyone’s feedback, and I’d be happy to work on establishing this system.

No files or tests are named. Start by reviewing Rslint’s existing pull-request CI and the Rspack binary-size comparison approach, then define how to build the stripped native executable, compare it with the base branch, and retain main-branch measurements. Done means pull requests report size changes and historical data shows the long-term trend.

Written by the indexing model from the issue text.