Runtime package inventory: loaded versions, drift and live advisories #68

Part of #51. Before asking "was the vulnerable function called?", ask "is the vulnerable package even loaded in production, and at which version?" That answer is cheap to get, needs no symbol data, and catches what a repo scan can't.

Probe side (#55, #56): once at startup, then whenever a new package is first imported, emit a load line (format in #53):

• Python: map sys.modules to distributions with importlib.metadata.packages_distributions(), and record name plus version.
• Node: for each newly resolved file under node_modules, read the nearest package.json once and record name, version and install path (nested copies are separate entries).

Server side: compare each app's loaded inventory with the project's latest SCA results:

First seen in production: record first_seen per (app, env, package, version). A package that appears in production for the first time after the baseline (the first 24 h of a sensor's life, configurable) is flagged as new, even if it has no known advisory.

Real-time advisories: secfoo runtime recheck (and a background job in secfoo serve, default every 6 h) queries OSV querybatch for every package version currently loaded in any app. A new advisory against a running version raises a finding immediately, with no new scan.

Export: secfoo runtime inventory --app <name> --env <env> --format cyclonedx writes a runtime SBOM of what is actually loaded.

Where to look: src/secfoo/osv.py, src/secfoo/report/sca.py, and the runtime_evidence storage from #53.

Done when: tests cover all four cases in the table using fixture inventories and fixture OSV responses (no network), plus a recheck that finds a newly published advisory.