Comment each pull request's shape and coverage #33

Parent

#21

What to build

Each pull request gets one comment, updated in place, that says what kind of change it is and what it did to coverage. It shows the changed files and lines by bucket (production code, tests, specification, decision records, documentation, examples, oracle files, tooling, CI, generated, and the coursework implementation under emf/ as one bucket of its own, so a pull request's split between the two implementations is visible), the branch's coverage beside a baseline cached from main with the difference, and the coverage of the lines the pull request changed. When no baseline is cached, the comment says so rather than showing no difference.

A job that gates nothing writes the comment, and it tolerates its own failure: coverage stays enforced by the thresholds. The rendering is one pure function over plain data, and it is tested; the collecting and posting steps carry no logic worth a test. A test keeps every tracked file in a bucket, so a renamed directory cannot fall into the fallback unnoticed.

Acceptance criteria

• A pull request shows the comment, and a second push updates the same comment instead of adding one.
• The comment shows the main baseline with its commit, or says there is none.
• A failure in the comment job does not fail Pipeline Complete.
• The bucket test fails for a tracked file that falls into the fallback.

Blocked by

• Run the suite on Vitest and make the tooling strict TypeScript #22
• Split CI into one job per gate under Pipeline Complete #23