[FEATURE]: add threat detection coverage field to AI/ML-BOM (modelCard.threatDetection)

This issue proposes adding a threat-detection coverage field to the AI/ML-BOM (modelCard) so that an AI/ML-BOM can declare which detection rulesets the model or agent artifact was scanned against, at what version, and with what outcome. The current AI/ML-BOM captures provenance, model parameters, considerations, and quantitative analysis, but does not capture agent-specific or model-specific threat detection coverage. As more AI agent artifacts (Model Context Protocol servers, Claude Code skills, agent configuration manifests) ship through SBOM-aware supply chains, consumers and registries are starting to ask: was this artifact scanned against a known agent-threat ruleset, which ruleset, which version, and what was the outcome.

I am proposing this as an issue rather than a PR because the right schema location (modelCard.threatDetection vs a separate top-level vs a CDXA attestation) is a design call that benefits from maintainer input before code changes. Concrete sketch in JSON Schema style for a modelCard.threatDetection field:

threatDetection: object, optional, describing the detection coverage applied to the AI/ML artifact.

threatDetection.scans: array of scan objects, each describing one scan run.

scans[].scanner: object with uri (ResourceURI) and version (string), identifying the tool that performed the scan.

scans[].ruleset: object with uri (ResourceURI) and version (string), identifying the ruleset that was applied. The version SHOULD be stable so a consumer can resolve any matched rule identifier.

scans[].scannedAt: timestamp (RFC 3339).

scans[].outcome: enum string, one of pass, warn, fail.

scans[].matches: optional array of matched rules; each match has ruleId (string), severity (low/medium/high/critical), threatClass (string, e.g. prompt_injection, tool_poisoning, mcp_request_forgery, skill_compromise), and optional evidence (string).

This is ruleset-agnostic. One concrete example of a ruleset that fits is Agent Threat Rules (ATR), an open detection standard for AI agent threats licensed Apache-2.0, available at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR is currently shipped in production at Cisco AI Defense and Microsoft agent-governance-toolkit. The proposed field is not coupled to ATR; any ruleset issuing stable identifiers can populate it.

Three questions I would like maintainer guidance on before opening a PR. First, is modelCard.threatDetection the right home, or would maintainers prefer this as a CDXA attestation that references the BOM subject? Second, should the matched rule identifiers live inline in the BOM, or should the BOM reference an external attestation (in-toto or otherwise) and only carry a coverage summary? Third, given the cap: ai/ml label and capability scope, should this be scoped to AI/ML-BOM only, or generalized to any component that may have a corresponding agent-threat scan? I will draft schema text for whichever direction maintainers prefer and follow up with a PR.