Correlate live traffic with the threat model's entry points #70

Part of #51. Secfoo already threat-models these applications. With live traffic data, the threat model can be checked against what really runs in production.

1. Make entry points machine-readable. ## 2. Scope & Assets in the threat-modeling output (src/secfoo/skills/renderer.py) currently lists entry points as prose. Add a table that cross-references the existing Bn boundaries:

| ID | Entry point | Interface | Route / pattern | Boundary |
|----|-------------|-----------|-----------------|----------|
| E1 | Public upload API | HTTP | POST /upload | B1 |

Parse it the way the Threat Register is parsed today, and keep older reports that lack it working.

2. Correlate. Match the route templates observed by sensors (#69) for an app with its project's latest threat model:

• Live entry point: an En that received traffic. Threats on its boundary get a "seen in production" marker, so a Gap threat on a live internet-facing boundary sorts above one on a boundary that saw no traffic.
• Unmodeled entry point: a route receiving traffic that no En covers. This is threat-model drift. Show it on the project page and offer to re-run threat-modeling with the unmodeled routes added as context.
• Vulnerable code behind a modeled boundary: an SCA finding that is Reached from traffic through a route mapped to an En gets that entry point's boundary. Example: "reached via E1 (B1: Internet → API)".

3. Show it. On the threat model run page and the project overview, show live/unmodeled entry points, and on SCA findings, show the boundary. Use the existing components in design-system/.

Done when: tests cover parsing the entry-point table (present and absent), route matching (exact, templated, unmatched) and threat ordering with live entry points. A screenshot goes in the PR.