feat: formalize canonical internal finding model

[meisterware-admin]

Summary

This PR implements Issue #4 by formalizing the internal normalized finding model used across the Detektor scan pipeline.

The change tightens Finding and Evidence as the canonical internal structures for detected security issues, adds canonical taxonomy and severity constants aligned with OpenPAKT, and updates the current MVP rules to emit stable canonical values consistently. The goal is to make findings the clear internal pipeline currency before Issue #5 report generation.

---

Type of change

Select all that apply:

• Bug fix
• New feature
• Detection rule improvement
• CLI improvement
• Documentation update
• Example update
• CI / tooling update
• Refactoring / non-functional cleanup

---

Related issue

Closes #4

---

What changed

• formalized Finding as the canonical normalized internal model with:
  • id
  • type
  • severity
  • component
  • description
  • evidence
• formalized structured Evidence with:
  • summary
  • optional location
  • optional snippet
• added canonical taxonomy constants in Detektor.OpenPAKT.Constants.FindingTypes
• added Detektor-side canonical references for taxonomy and severity usage in rules and tests
• updated PromptInjectionRule and ToolPermissionValidationRule to emit canonical OpenPAKT-aligned values consistently
• added focused finding model tests
• updated rule and rule engine tests to verify canonical type/severity usage and deterministic aggregation behavior

---

Impact

This change makes the internal finding model the clear canonical structure used between rule execution, aggregation, and future report mapping.

Expected impact:

• more consistent scanner behaviour across rules
• easier mapping to OpenPAKT report generation in the next issue
• better confidence in deterministic and strongly typed finding handling
• improved developer clarity around canonical taxonomy and severity usage

This PR does not change report output, CLI behaviour, or add new reporting/policy/scenario features.

---

Compatibility

Choose one:

• Backward compatible
• Additive change
• Breaking change
• Not applicable

If Breaking change, explain migration considerations.

---

Checklist

• Change aligns with Detektor project goals
• Related documentation has been updated if needed
• Example outputs or usage have been updated if needed
• Compatibility impact has been considered
• This PR keeps the implementation minimal and focused

---

Notes for reviewers

This PR is intentionally scoped only to Issue #4.

It does not implement:

• OpenPAKT report writing
• JSON serialization or file emission
• CI policy evaluation
• scenario execution
• plugin/extensibility architecture

Verification completed:

• dotnet test Detektor.sln
• 26/26 tests passed