CI: report PR changed-line breakdown by src / tests / docs

### Use case

When reviewing a PR, it is often useful to quickly see **how much of the change is production source vs tests vs docs**, rather than only the total `+`/`-` count shown by GitHub.

Example of the kind of summary that would help:

| Area | Added | Deleted | Net / total changed |
| --- | ---: | ---: | ---: |
| `src/` | … | … | … |
| `tests/` | … | … | … |
| `docs/` | … | … | … |
| other (`ci/`, `programs/`, …) | … | … | … |

This makes it easier to answer questions like:

- Is this mostly a docs-only or tests-only PR?
- How large is the real product code change, after excluding tests/docs?
- Does the PR look under-tested relative to the size of `src/` changes?

### Current status

CI today:

- tracks `changed_files` for job filtering (e.g. docs-only / tests-only skips), but does **not** publish a per-directory line-count summary;
- coverage reports talk about *PR changed lines* coverage for C/C++, which is related but not a change-size breakdown;
- GitHub’s PR UI only shows aggregate additions/deletions and a file list.

### Proposal

Discuss whether it is worth adding a lightweight CI report (robot comment, Style Check / CI summary section, or Praktika report artifact) that summarizes changed lines by top-level area, at least:

- `src/`
- `tests/`
- `docs/`
- optionally `ci/`, `programs/`, `contrib/`, and “other”

Implementation could be as simple as parsing `git diff --numstat` against the merge base / `master`.

### Questions

1. Is this useful enough for reviewers / authors to justify a CI surface?
2. If yes, where should it appear (PR comment, existing CI job summary, both)?
3. Any preferred grouping beyond `src` / `tests` / `docs`?
4. Should renames / generated docs / `contrib/` be called out separately so the numbers stay meaningful?

Happy to help implement if we think this is a good idea.

No implementation files or tests are named. Start by reading the existing changed_files filtering and the current Style Check, CI summary, and Praktika report entry points, then inspect how git diff --numstat could be measured against master; done requires an agreed report location, grouping, and handling for renames and generated docs.

Written by the indexing model from the issue text.