[Feature]: Generate an SBOM during packaging and publish it with the release

### Background and motivation

The build already produces a build provenance attestation (#35, #68). An SBOM is the other half of that story: provenance says *who built it*, an SBOM says *what is inside it*. Consumers in regulated industries increasingly ask for both, and it is far easier to generate one from the start than to bolt it on later.

Proposal: add a build target that produces an SBOM during packaging and publishes it alongside the package.

Options worth comparing:

* `Microsoft.Sbom.Tool` — produces SPDX, is the Microsoft-blessed route, and has a .NET global tool.
* `CycloneDX` (`CycloneDX.DotNet`) — produces CycloneDX, and integrates well with dependency scanners.

The SBOM should be uploaded as a build artifact, attached to the GitHub release, and ideally attested the same way the `.nupkg` already is.

### Alternative Concerns

* This adds another tool to the build, so it should be a target that can be skipped, in the same way `ScanPackages` can be.
* PackageGuard already inspects the dependency graph for licences (#12), so there is some overlap. The difference is that an SBOM is an artefact you *ship*, not a check you run.
* For Azure DevOps, the equivalent is the SBOM task, so the two pipelines will need slightly different wiring.

### Could you help with a pull-request?

No

Start by comparing the packaging target with the existing ScanPackages target, then inspect how the GitHub and Azure DevOps pipelines publish the .nupkg and release artifacts. Compare Microsoft.Sbom.Tool with CycloneDX.DotNet, including the attestation approach. Done means an optional SBOM target generates the selected format, uploads it as an artifact, and publishes it with the release in both pipeline environments.

Written by the indexing model from the issue text.