[SizzleUnrlsd]

Summary

Last Phase 5 item of docs/architecture.md: detectors on the shared taint engine (§15 Analysis Providers and Detectors, §25 Plugin Types, §35–§36).

• Acceptance tests first (test: define detector and model plugin behavior), implementation follows.
• Plugin.models: any plugin may contribute Source, Sink and Sanitizer models; ModelPlugin is the provider-only kind of §15. The engine loads every plugin first, collects their models into one registry, then provides the table, so framework models and detectors compose without knowing each other.
• Two reusable bases in the plugin API. TaintDetector turns the flows of one taint kind into findings with source label, sink symbol and location. SymbolCallDetector reports calls whose callee resolves to a canonical symbol by reading the SSA form, so local aliases such as show = print; show(x) are followed.
• Shipped plugins under plugins/: models/python_stdlib (stdin, argv and environment sources; command, code, path and SSRF sinks; shlex.quote, html.escape and os.path.basename sanitizers), security/{sql_injection,command_injection,path_traversal,ssrf,xss}, syntax/weak_crypto. dangerous_eval now sits on the shared base.
• Manifests declare requires = ["taint.flows"] and provides = ["vulnerability.<rule>"]; the loader checks them against the classes.

End to end: --check on os.system(input()) reports a command injection; a test-written model plugin providing HTTP sources and SQL/HTML sinks turns the same detectors into SQL injection and XSS findings, rendered to SARIF.

Known limitation, unchanged by this PR: a function using syntax outside the lowering subset (nested definitions, keyword arguments, ...) aborts the whole check with a diagnostic instead of being skipped.

Closes #23