feat(crypto): Complete Phase 2 - Configuration-driven crypto architecture with 100% compliance

## Summary

This commit completes Phase 2 of the configuration-driven crypto architecture, achieving
100% crypto compliance by eliminating all hardcoded cryptographic implementations.

## Key Changes

### Phase 1: Plugin Loader Infrastructure
- **Plugin Discovery System**: Created StellaOps.Cryptography.PluginLoader with manifest-based loading
- **Configuration Model**: Added CryptoPluginConfiguration with regional profiles support
- **Dependency Injection**: Extended DI to support plugin-based crypto provider registration
- **Regional Configs**: Created appsettings.crypto.{international,russia,eu,china}.yaml
- **CI Workflow**: Added .gitea/workflows/crypto-compliance.yml for audit enforcement

### Phase 2: Code Refactoring
- **API Extension**: Added ICryptoProvider.CreateEphemeralVerifier for verification-only scenarios
- **Plugin Implementation**: Created OfflineVerificationCryptoProvider with ephemeral verifier support
  - Supports ES256/384/512, RS256/384/512, PS256/384/512
  - SubjectPublicKeyInfo (SPKI) public key format
- **100% Compliance**: Refactored DsseVerifier to remove all BouncyCastle cryptographic usage
- **Unit Tests**: Created OfflineVerificationProviderTests with 39 passing tests
- **Documentation**: Created comprehensive security guide at docs/security/offline-verification-crypto-provider.md
- **Audit Infrastructure**: Created scripts/audit-crypto-usage.ps1 for static analysis

### Testing Infrastructure (TestKit)
- **Determinism Gate**: Created DeterminismGate for reproducibility validation
- **Test Fixtures**: Added PostgresFixture and ValkeyFixture using Testcontainers
- **Traits System**: Implemented test lane attributes for parallel CI execution
- **JSON Assertions**: Added CanonicalJsonAssert for deterministic JSON comparisons
- **Test Lanes**: Created test-lanes.yml workflow for parallel test execution

### Documentation
- **Architecture**: Created CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md master plan
- **Sprint Tracking**: Created SPRINT_1000_0007_0002_crypto_refactoring.md (COMPLETE)
- **API Documentation**: Updated docs2/cli/crypto-plugins.md and crypto.md
- **Testing Strategy**: Created testing strategy documents in docs/implplan/SPRINT_5100_0007_*

## Compliance & Testing

- ✅ Zero direct System.Security.Cryptography usage in production code
- ✅ All crypto operations go through ICryptoProvider abstraction
- ✅ 39/39 unit tests passing for OfflineVerificationCryptoProvider
- ✅ Build successful (AirGap, Crypto plugin, DI infrastructure)
- ✅ Audit script validates crypto boundaries

## Files Modified

**Core Crypto Infrastructure:**
- src/__Libraries/StellaOps.Cryptography/CryptoProvider.cs (API extension)
- src/__Libraries/StellaOps.Cryptography/CryptoSigningKey.cs (verification-only constructor)
- src/__Libraries/StellaOps.Cryptography/EcdsaSigner.cs (fixed ephemeral verifier)

**Plugin Implementation:**
- src/__Libraries/StellaOps.Cryptography.Plugin.OfflineVerification/ (new)
- src/__Libraries/StellaOps.Cryptography.PluginLoader/ (new)

**Production Code Refactoring:**
- src/AirGap/StellaOps.AirGap.Importer/Validation/DsseVerifier.cs (100% compliant)

**Tests:**
- src/__Libraries/__Tests/StellaOps.Cryptography.Plugin.OfflineVerification.Tests/ (new, 39 tests)
- src/__Libraries/__Tests/StellaOps.Cryptography.PluginLoader.Tests/ (new)

**Configuration:**
- etc/crypto-plugins-manifest.json (plugin registry)
- etc/appsettings.crypto.*.yaml (regional profiles)

**Documentation:**
- docs/security/offline-verification-crypto-provider.md (600+ lines)
- docs/implplan/CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md (master plan)
- docs/implplan/SPRINT_1000_0007_0002_crypto_refactoring.md (Phase 2 complete)

## Next Steps

Phase 3: Docker & CI/CD Integration
- Create multi-stage Dockerfiles with all plugins
- Build regional Docker Compose files
- Implement runtime configuration selection
- Add deployment validation scripts

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

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

docs2/notifications/channels.md

@@ -0,0 +1,26 @@
+# Notification channels
+
+Supported types
+- Slack and Teams via webhooks.
+- Email via SMTP or relay.
+- Generic webhook and escalation webhook.
+- Console in-app delivery.
+
+Channel schema (summary)
+- id, tenant, type, endpoint, secretRef, labels.
+- throttle and quietHours.
+- enabled flag and createdUtc timestamp.
+
+Security and determinism
+- No secrets stored in Notify DB; use secretRef.
+- Endpoints must be allowlisted.
+- Webhook payloads use HMAC-SHA256 with nonce and timestamp.
+- Deterministic channel ids for manifest-based creation.
+
+Offline posture
+- Offline kits include placeholder channel manifests.
+- Operators replace endpoints and secretRefs before deployment.
+
+Related references
+- docs/notifications/channels.md
+- docs/notifications/architecture.md

docs2/notifications/digests.md

@@ -0,0 +1,20 @@
+# Notification digests
+
+Digests coalesce matching events into scheduled summaries to reduce noise.
+
+Digest lifecycle
+- Rule action selects digest window (instant, 5m, 15m, 1h, 1d).
+- Worker aggregates events per tenant and action.
+- Window flush renders a digest template and emits a delivery.
+
+Storage and audit
+- Digest documents store window metadata and items.
+- Delivery ledger links to digest ids for traceability.
+
+Safety and determinism
+- Idempotent digest delivery ids per window.
+- Throttles and quiet hours are respected.
+- Workers resume open windows after restart.
+
+Related references
+- docs/notifications/digests.md

docs2/notifications/overview.md

@@ -0,0 +1,24 @@
+# Notifications overview
+
+Notifications Studio turns platform events into tenant-scoped alerts with
+explainable routing and deterministic outputs.
+
+Core capabilities
+- Rules engine for event matching, VEX gating, throttles, and digests.
+- Channel connectors (Slack, Teams, Email, Webhook, Console).
+- Deterministic templates and locale-aware rendering.
+- Delivery ledger for audit and replay.
+
+Operational model
+- Notify.Worker evaluates rules per event and tenant.
+- Actions are idempotent; throttles and digests are recorded.
+- API access uses notify.viewer, notify.operator, notify.admin scopes.
+
+Offline posture
+- Offline kits ship rules, templates, and plugins.
+- No external SaaS required for core delivery.
+
+Related references
+- docs/notifications/overview.md
+- docs/notifications/architecture.md
+- docs2/operations/notifications.md

docs2/notifications/pack-approvals.md

@@ -0,0 +1,33 @@
+# Pack approvals notifications
+
+Purpose
+- Ingest pack approval events from Task Runner.
+- Persist approval state and notify approvers.
+- Provide acknowledgement and resume hooks.
+
+Event contract
+- approval requested and approval updated events.
+- Fields include runId, approvalId, plan hash, tenant, required grants,
+  step identifiers, and resume callback metadata.
+
+Ingestion and persistence
+- Secure endpoint validates scopes and tenant header.
+- Approval records stored with idempotent keys (runId + approvalId).
+- Audit records capture delivery attempts and correlation ids.
+
+Routing and templates
+- Rules match event.kind = pack.approval.
+- Templates include plan metadata and approval links.
+- Policy hold notifications are surfaced as incidents.
+
+Ack and resume
+- Ack endpoint records decision metadata and forwards resume callback.
+- Idempotent updates based on decision hash.
+
+Security and observability
+- HMAC or mTLS between Task Runner and Notify.
+- Metrics for queued, sent, and pending approvals.
+
+Related references
+- docs/notifications/pack-approvals-integration.md
+- docs/notifications/pack-approvals-contract.md

docs2/notifications/rules.md

@@ -0,0 +1,28 @@
+# Notification rules
+
+Rule lifecycle
+- Create and update via Notify API or UI.
+- Worker evaluates rules per tenant and event.
+- Actions are queued with idempotency keys.
+- Delivery ledger references ruleId and actionId.
+
+Rule schema (summary)
+- ruleId, tenantId, name, enabled.
+- match filters for eventKinds, namespaces, labels, severity, verdicts.
+- VEX gates can include or exclude justifications.
+- actions define channel, template, digest window, throttle, locale.
+
+Match filters
+- eventKinds, namespaces, repositories, digests, labels.
+- minSeverity and kevOnly gates.
+- VEX justification allowlists when present.
+
+Actions, throttles, digests
+- actionId and channel are required.
+- digest windows: instant, 5m, 15m, 1h, 1d.
+- throttles prevent repeat deliveries for identical events.
+
+Related references
+- docs/notifications/rules.md
+- docs2/notifications/digests.md
+- docs2/notifications/templates.md

docs2/notifications/templates.md

@@ -0,0 +1,25 @@
+# Notification templates
+
+Templates define deterministic payloads per channel and locale.
+
+Template lifecycle
+- Create templates via API or UI.
+- Rule actions reference template keys.
+- Worker renders templates with a safe helper set.
+
+Template schema (summary)
+- templateId, tenantId, channelType, key, locale.
+- body, renderMode, format, metadata.
+- schemaVersion is normalized on persistence.
+
+Template context
+- event, scope, payload, rule, action, policy.
+- topFindings and digest metadata when available.
+
+Attestation lifecycle templates
+- Dedicated template keys for attestation failures, expiries,
+  key rotation, and transparency anomalies.
+- Templates must include subject, signer, and evidence links.
+
+Related references
+- docs/notifications/templates.md