[SizzleUnrlsd]

Summary

Opens Phase 9 of docs/architecture.md: dependency analysis (§26) and the first step of the correlation of §27, "vulnerable package + affected API reachable".

• Acceptance tests first (test: define dependency analysis behavior), implementation follows.
• coretrace_python.dependency: Requirement, Version (a PEP 440 subset with ==, !=, <, <=, >, >=, ~= and Poetry's ^), DependencyGraph, Advisory (package, vulnerable range, affected APIs) and parsers for requirements*.txt, pyproject.toml (PEP 621 and Poetry) and the poetry.lock / uv.lock lockfiles, which pin the declared requirements when merged. Nothing is downloaded. A requirement "may match" a vulnerable range when its pin is inside it, or when some version it allows is.
• DependencyAnalysis (dependency.graph) is an engine-provided input like the security models; a lone file sees an empty graph.
• Plugin API: any plugin may contribute advisories; ProjectPlugin runs once per project with a ProjectContext exposing the module graph, the dependency graph, all advisories and each module's imports and call graph. engine.analyze_project also accepts plugin instances directly.
• Shipped under plugins/dependency: sample-advisories (a small offline sample of published CVEs with the APIs they affect), vulnerable-dependency (a requirement allows a vulnerable version, at its line, high confidence when pinned and medium otherwise) and reachable-vulnerability (a call anywhere in the project to an affected API of a vulnerable requirement, at the call site).
• Layer map: dependency sits above findings, below plugins.

Example: pyyaml==5.3.1 in requirements.txt plus yaml.load(text) in a module yields a critical reachable-vulnerability at the call and a critical vulnerable-dependency at the requirement line.

Not in this PR: live OSV/GHSA feeds, policy plugins, secret detection, SBOM, and the taint side of the correlation (attacker-controlled data reaching the affected API).

Part of #37