feat: Add metadata fields to security checks (layer, phase, use case, framework)

## Summary

Each security check currently has severity, service, and status. Adding structured categorization fields would improve filtering, reporting, and compliance mapping — and unlock the work in issues for NIST AI RMF mapping and multi-tab report structure.

## Proposed Fields

| Field | Example values |
|---|---|
| `layer` | `Infrastructure`, `Data`, `Model`, `Application`, `Agent` |
| `phase` | `Build`, `Deploy`, `Runtime`, `Monitor` |
| `use_case` | `RAG`, `Fine-tuning`, `Inference`, `Agent` |
| `framework` | `Well-Architected GenAI Lens`, `OWASP LLM Top 10`, `NIST AI RMF` |

## Files Likely Touched

- All assessor files in `aiml-security-assessment/functions/security/*/` — add fields to each check result dict
- HTML report template — add new filter dropdowns for these fields
- `docs/SECURITY_CHECKS.md` and `docs/AIMLSecurityAssessment-MappingsTable.csv` — add new columns

## Acceptance Criteria

- [ ] All existing checks have values for all four new fields
- [ ] Report UI exposes filters for each new field
- [ ] CSV export includes the new columns
- [ ] Developer guide documents the expected field values and allowed vocabulary

## Notes

This is a foundational issue — NIST AI RMF / ISO 42001 mapping and the multi-tab report structure both depend on these fields being present. Recommended to tackle this first.

Begin with the assessor files under aiml-security-assessment/functions/security/*/ and inspect the existing check result dictionaries, then review the HTML report template and the documentation files named in the issue. Add the four metadata fields consistently, expose report filters, include the fields in the CSV, and document their allowed values. Done means every existing check has all four fields and each acceptance criterion is met.

Written by the indexing model from the issue text.