feat: add phase-level latency metrics for container scans

[bdemeo12]

• Ready for review
• Follows CONTRIBUTING rules
• Reviewed by Snyk internal team

What does this PR do?

Adds per-phase latency timing to the container scan flow. Each major phase (image extraction, OS package analysis, JAR/Go/Node/PHP/Python analysis, binary detection, dep tree building) is timed with Date.now() and returned on the PluginResponse via a new optional analytics field. A companion CLI change wires these timings into CLI analytics metadata as containerPluginTimings.

Any background context you want to provide?

The container plugin has no latency visibility, this PR is to collect latency metrics and surface them in the CLI analytics.

What are the relevant tickets?

https://snyksec.atlassian.net/browse/CN-1170
https://snyksec.atlassian.net/browse/CN-1054

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Unsafe Spread of Optional Timings 🟡 [minor] In analyzeStatically, the code spreads staticAnalysis.timings. While the interface StaticAnalysis in lib/analyzer/types.ts defines timings as optional, the analyze function in static-analyzer.ts always initializes it. However, if staticAnalysis.timings were ever undefined (e.g., from a mock or future code path), spreading it into a new object is safe in modern JS, but it could lead to missing data in the containerPluginTimings analytics event without a fallback. const timings: Record<string, number> = { ...staticAnalysis.timings, depTreeBuildingMs, totalMs, };

📚 Repository Context Analyzed This review considered 15 relevant code sections from 10 files (average relevance: 0.72) lib/scan.ts (lines 1-247) lib/response-builder.ts (3 segments, lines 17-27) lib/extractor/index.ts (lines 1-229) lib/analyzer/applications/node.ts (lines 274-527) lib/inputs/rpm/static.ts (lines 1-117) lib/analyzer/static-analyzer.ts (3 segments, lines 92-350) lib/static.ts (lines 1-101) ... and 3 more file(s)