[Feature]: First-party GitHub Action with SARIF violation annotations on pull requests

### Background and motivation

Running PackageGuard in CI currently means writing a workflow step by hand, installing the global tool, and parsing console output to work out what went wrong. Results appear only in the build log.

A first-party action would remove that friction and, more importantly, put results where developers actually look: inline on the pull request.

**Proposal**

Publish `dennisdoomen/packageguard-action@v1`:

```yaml
- uses: dennisdoomen/packageguard-action@v1
with:
path: .
config-path: .packageguard/config.json
report-risk: true
upload-sarif: true
```

Design points:

- **SARIF for violations, not just risk.** PackageGuard already writes SARIF for risk reports. Emitting policy violations as SARIF too, with `physicalLocation` pointing at the `.csproj` / `package.json` line that declares the offending package, means GitHub renders them as annotations on the changed lines. That turns "the build failed" into "this line is the problem".
- **Line-level locations.** This requires mapping a package back to the `PackageReference` element or `package.json` entry that introduced it. For transitive packages there is no such line, so those should point at the nearest direct ancestor's declaration with an explanatory message.
- **Code scanning integration.** Uploading via `github/codeql-action/upload-sarif` puts violations in the Security tab, gives them a lifecycle (open/fixed/dismissed) and lets teams use existing triage workflows rather than inventing new ones.
- **PR summary.** Writing a Markdown table to `$GITHUB_STEP_SUMMARY` gives a readable overview without needing to open the log.
- **Container vs composite.** A composite action that installs the .NET tool is simpler and keeps versioning aligned with the NuGet package; a container action starts faster but needs a published image. The composite route is probably the right first step.
- **Outputs.** Expose `violation-count`, `highest-risk-score` and the report paths as action outputs so downstream steps can react.

This depends on machine-readable output being available, so it pairs naturally with the `--output` work.

### Alternative Concerns

- Teams can write their own workflow step today, and many will. But the SARIF/annotation integration is the part that is genuinely awkward to do by hand, and it is the part that makes the tool feel native to GitHub.
- An Azure DevOps extension would serve a large part of the .NET audience too, and is worth a separate issue.

### Are you willing help with a pull-request?

No

Start by reviewing the existing SARIF risk-report generation and the planned machine-readable --output work. Define the composite action around the shown inputs, then determine how .csproj and package.json declarations map violations to SARIF locations, including transitive packages. Done means the action publishes reports, annotations, a PR summary, and the specified outputs.

Written by the indexing model from the issue text.