feat(cli): Implement crypto plugin CLI architecture with regional compliance

Sprint: SPRINT_4100_0006_0001
Status: COMPLETED

Implemented plugin-based crypto command architecture for regional compliance
with build-time distribution selection (GOST/eIDAS/SM) and runtime validation.

## New Commands

- `stella crypto sign` - Sign artifacts with regional crypto providers
- `stella crypto verify` - Verify signatures with trust policy support
- `stella crypto profiles` - List available crypto providers & capabilities

## Build-Time Distribution Selection

```bash
# International (default - BouncyCastle)
dotnet build src/Cli/StellaOps.Cli/StellaOps.Cli.csproj

# Russia distribution (GOST R 34.10-2012)
dotnet build -p:StellaOpsEnableGOST=true

# EU distribution (eIDAS Regulation 910/2014)
dotnet build -p:StellaOpsEnableEIDAS=true

# China distribution (SM2/SM3/SM4)
dotnet build -p:StellaOpsEnableSM=true
```

## Key Features

- Build-time conditional compilation prevents export control violations
- Runtime crypto profile validation on CLI startup
- 8 predefined profiles (international, russia-prod/dev, eu-prod/dev, china-prod/dev)
- Comprehensive configuration with environment variable substitution
- Integration tests with distribution-specific assertions
- Full migration path from deprecated `cryptoru` CLI

## Files Added

- src/Cli/StellaOps.Cli/Commands/CryptoCommandGroup.cs
- src/Cli/StellaOps.Cli/Commands/CommandHandlers.Crypto.cs
- src/Cli/StellaOps.Cli/Services/CryptoProfileValidator.cs
- src/Cli/StellaOps.Cli/appsettings.crypto.yaml.example
- src/Cli/__Tests/StellaOps.Cli.Tests/CryptoCommandTests.cs
- docs/cli/crypto-commands.md
- docs/implplan/SPRINT_4100_0006_0001_COMPLETION_SUMMARY.md

## Files Modified

- src/Cli/StellaOps.Cli/StellaOps.Cli.csproj (conditional plugin refs)
- src/Cli/StellaOps.Cli/Program.cs (plugin registration + validation)
- src/Cli/StellaOps.Cli/Commands/CommandFactory.cs (command wiring)
- src/Scanner/__Libraries/StellaOps.Scanner.Core/Configuration/PoEConfiguration.cs (fix)

## Compliance

- GOST (Russia): GOST R 34.10-2012, FSB certified
- eIDAS (EU): Regulation (EU) No 910/2014, QES/AES/AdES
- SM (China): GM/T 0003-2012 (SM2), OSCCA certified

## Migration

`cryptoru` CLI deprecated → sunset date: 2025-07-01
- `cryptoru providers` → `stella crypto profiles`
- `cryptoru sign` → `stella crypto sign`

## Testing

✅ All crypto code compiles successfully
✅ Integration tests pass
✅ Build verification for all distributions (international/GOST/eIDAS/SM)

Next: SPRINT_4100_0006_0002 (eIDAS plugin implementation)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

docs/product-advisories/archived

@@ -0,0 +1,33 @@
+I’m sharing this because the way *signed attestations* and *SBOM formats* are evolving is rapidly reshaping how supply‑chain security tooling like Trivy, in‑toto, CycloneDX, SPDX, and Cosign interoperate — and there’s a clear gap right now you can exploit strategically.
+
+![Image](https://www.cncf.io/wp-content/uploads/2023/08/Screenshot-Capture-2023-07-24-11-26-33.png)
+
+![Image](https://owasp.org/assets/images/posts/cdx-attestations/image1.png)
+
+![Image](https://edu.chainguard.dev/chainguard/chainguard-images/staying-secure/working-with-scanners/trivy-tutorial/trivy_output.png)
+
+![Image](https://edu.chainguard.dev/chainguard/chainguard-images/staying-secure/working-with-scanners/trivy-tutorial/trivy-html-report.png)
+
+**Attested‑first scanning and in‑toto/DSSE as truth anchors**
+• The core idea is to *treat attestations themselves as the primary artifact to verify*. An in‑toto/DSSE attestation isn’t just an SBOM — it’s a *signed cryptographic statement* about the SBOM or other metadata (build provenance, test results, etc.), enabling trust decisions in CI/CD and runtime. ([SLSA][1])
+• Tools like *Cosign* generate and verify these in‑toto attestations — you can use `cosign verify‑attestation` to extract the SBOM payload from a DSSE envelope before scanning. ([Trivy][2])
+• CycloneDX’s attestation work (often referenced as **CDXA**) formalizes how attestations describe compliance claims and can *automate audit workflows*, making them machine‑readable and actionable. ([CycloneDX][3])
+
+**Trivy’s dual‑format SBOM and attestation support — and the current parity gap**
+• *Trivy* already ingests *CycloneDX‑type SBOM attestations* (where the SBOM is wrapped in an in‑toto DSSE envelope). It uses Cosign‑produced attestations as inputs for its SBOM scanning pipeline. ([Trivy][4])
+• Trivy also scans traditional CycloneDX and SPDX SBOMs directly (and supports SPDX‑JSON). ([Trivy][5])
+• However, *formal parsing of SPDX in‑toto attestations is still tracked and not fully implemented* (evidence from feature discussions and issues). This means there’s a *window where CycloneDX attestation support is ahead of SPDX attestation support*, and tools that handle both smoothly will win in enterprise pipelines. ([GitHub][6])
+• That gap — *full SPDX attestation ingestion and verification* — remains a differentiation opportunity: build tooling or workflows that standardize acceptance and verification of both attested CycloneDX and attested SPDX SBOMs with strong replayable verdicts.
+
+**Why this matters right now**
+Signed attestations (via DSSE/in‑toto and Cosign) turn an SBOM from a passive document into a *verified supply‑chain claim* that can gate deployments and signal compliance postures. Tools like Trivy that ingest these attestations are at the forefront of that shift, but not all formats are on equal footing yet — giving you space to innovate workflows or tooling that closes the parity window. ([Harness][7])
+
+If you want follow‑up examples of commands or how to build CI/CD gates around these attestation flows, just let me know.
+
+[1]: https://slsa.dev/blog/2023/05/in-toto-and-slsa?utm_source=chatgpt.com "in-toto and SLSA"
+[2]: https://trivy.dev/v0.40/docs/target/sbom/?utm_source=chatgpt.com "SBOM scanning"
+[3]: https://cyclonedx.org/capabilities/attestations/?utm_source=chatgpt.com "CycloneDX Attestations (CDXA)"
+[4]: https://trivy.dev/docs/latest/supply-chain/attestation/sbom/?utm_source=chatgpt.com "SBOM attestation"
+[5]: https://trivy.dev/docs/latest/target/sbom/?utm_source=chatgpt.com "SBOM scanning"
+[6]: https://github.com/aquasecurity/trivy/issues/9828?utm_source=chatgpt.com "feat(sbom): add support for SPDX attestations · Issue #9828"
+[7]: https://developer.harness.io/docs/security-testing-orchestration/sto-techref-category/trivy/aqua-trivy-scanner-reference?utm_source=chatgpt.com "Aqua Trivy step configuration"