feat: add guidelines-security-analysis skill (architecture, questionnaire, threat model, enforcement mapping)

[iamsreec]

Summary

Adds the guidelines-security-analysis skill: a 4-step pipeline (architecture analysis -> policy guidance questionnaire -> threat model -> enforcement mapping) that turns a target MCP server's source and OWASP Top 10 for Agentic AI Security (ASI01–ASI10) catalog into a scoped set of security guidelines for OPA policy.

Closes: #issue-number

Changes

• opa_policy/guidelines-security-analysis/guidelines-security-analysis.md — new orchestrator doc that sequences the 4 steps
• opa_policy/guidelines-security-analysis/owasp/architecture_analysis.md — maps an MCP server's layers, trust boundaries, and OPA enforcement points into architecture.md
• opa_policy/guidelines-security-analysis/owasp/policy_guidance_questionnaire.md — derives a 22-question policy-intent questionnaire from architecture.md + guidance.txt/system_vars.json/tool_definitions.json where present
• opa_policy/guidelines-security-analysis/owasp/threat_model.md — evaluates all 10 ASI categories against the tool using a three-question applicability test, sourced live from the catalog rather than hardcoded
• opa_policy/guidelines-security-analysis/owasp/enforcement_mapping.md — maps each threat instance to an enforcement layer (OPA vs. agent/tool/infra) and produces plain-English policy-rule requirements grounded in the catalog's mitigations
• src/smith/data/owasp_10_ai_catalog.json — new repo-relative data file: the OWASP Top 10 for Agentic AI Security catalog (ASI01–ASI10), single source of truth for category names, descriptions, impact, mitigations, and attack scenarios

All four step docs share a consistent "Authoritative Paths" contract: inputs are read from ONLY the named files under <TARGET_AGENT_PATH>/smith/guidelines-security-analysis/ (or the repo-relative catalog path), with an explicit stop-and-ask instruction if a required file is missing.

Checks

• make ci passes (lint, Rego lint, license headers, build smoke)
• make test passes (policy scorecard — needed if policy behavior changed) — not applicable, no assets/policy.rego changes in this PR
• CHANGELOG.md updated under ## [Unreleased] (if user-facing)
• Commits are signed off for the DCO (git commit -s) — verified via git log -1 --format='%B', Signed-off-by present

Notes (optional)

Base branch should be hl/promptfoo_config_auto, not main — this skill was built on top of unreleased work already on that branch. Confirmed clean: git diff --stat hl/promptfoo_config_auto..feat/guidelines-security-analysis shows exactly these 6 files (1392 insertions, 0 deletions), no policy_build/CLI/example files leaking in.

[araujof]

Nice work!

Can you please look into the following issues, then should be good to go. Additional tests, examples, etc. can be open in a separate PR.

• Make the workflow discoverable: opa_policy/guidelines-security-analysis/guidelines-security-
  analysis.md:1 is not named SKILL.md, and the root SKILL.md:16 never routes security-analysis requests to it. Installed agents therefore won’t invoke this workflow.

• Fix the OPA input path: opa_policy/guidelines-security-analysis/owasp/enforcement_mapping.md:42
  consistently uses input.arguments.*, while Smith’s current canonical representation and policy workflow use input.args.*. Generated specifications can target nonexistent fields. Please check this with @dhl123 to confirm.

• It looks like opa_policy/guidelines-security-analysis/owasp/
  enforcement_mapping.md:334 considers overlapping value sets covered. If guidance blocks {exe} and the candidate blocks {exe, dll}, dll is silently omitted. Shuld coverage require the existing rule to contain the candidate’s full triggering set?