feat: scope the PHPCS gate to the lines a change actually touches

[arifulhoque7]

PHPCS reports whole files. On a codebase that already has violations, that means editing one line of a legacy file inherits every finding already in it, so the job is red however careful the author is, and people learn to ignore it.

Measured on the Elementor widgets branch (wedocs-plugin#324), which touches 16 PHP files:

	count
Security findings in those files	175
Security findings on lines that branch wrote	63

The other 112 sit in Ajax.php, API.php and functions.php and predate the branch entirely. Asking a feature PR to fix core AJAX and REST paths it merely touched is the wrong trade: it bloats the diff, risks regressions, and makes review impossible.

What this does

bin/phpcs-changed-lines.php reads the PHPCS JSON report, keeps only findings that land on added or modified lines, emits a GitHub annotation for each, and sets the exit status.

Only errors fail the run. Warnings are annotated but do not block, mirroring cs2pr --graceful-warnings, which the Dokan and WPUF workflows already use.

$ phpcs --standard=phpcs.xml.dist <changed files> -q --report=json \
    | php bin/phpcs-changed-lines.php "$(git rev-parse HEAD^1)"

PHPCS: 106 finding(s) on changed lines, ... (348 findings in these files overall).

The base is HEAD^1 of the pull_request merge commit, which is the base branch tip, so the same commit the file list is already derived from.

Effect

On #324, before its own fixes: 348 findings in the files, 106 on changed lines. That branch then closed all of its errors, and the gate passes there now.

Nothing about the ruleset changes. A file with pre-existing violations is still reported in full when you run composer phpcs locally; this only decides what blocks a merge.

Related: weDevsOfficial/plugin-internal-tasks#9

https://claude.ai/code/session_019wvVjJ8agR8TWAVrrKVESH