feat: Add opt-in PR comment posting to the GitHub Action

[Tgenz1213]

Problem

action.yml's only step that produces user-facing output is archguard check --ci (action.yml:37-39), which writes to the job's stdout log. On a pull request, nobody sees a violation unless they open the CI log — there's no summary posted where the PR is actually being reviewed, unlike tools (CodeQL, most linters-as-Actions) that comment directly on the PR.

Acceptance Criteria

• action.yml gains a new opt-in input, e.g. comment-on-pr (boolean, default false), so existing consumers' workflows are unaffected and nobody is silently granted extra GitHub permissions they didn't ask for.
• When comment-on-pr: true and the workflow is running on a pull_request event, a step posts (or updates, if one already exists from a prior run on the same PR — don't spam a new comment per push) a comment summarizing violations found by the archguard check --ci step.
• README and action.yml's input description both state that comment-on-pr: true requires the consumer's workflow to grant permissions: pull-requests: write (composite actions inherit the caller's token permissions and cannot request their own) — a bare uses: Tgenz1213/ArchGuard@main example in the README should show the required permissions: block.
• If comment-on-pr: true is set on a non-pull_request trigger (e.g. a push to main), the step is skipped without failing the run.
• Comment content is at minimum the same information already in the CI log for violations (ADR, file, line, reasoning) — reasonable to build on --format json (issue feat: Add machine-readable (--format json) output to archguard check #70) once available for a cleaner comment body, but that's an enhancement, not a blocker for v1.

Related

Depends loosely on #70 (--format json) for a well-structured comment body; v1 can parse/reuse the existing text output if #70 isn't done yet.