feat: feed dependency manifests to LLM for capability-accurate displayNames

[Yimin-Jin]

Summary

Improves LLM-generated displayName/description quality by feeding each sample's dependency manifests to the model, not just its README. This mirrors how a human reviewer verifies a name — a PM audit (gist) found that 2 of 4 "voicelive" samples don't actually use Azure Voice Live, so naming by folder/README alone is misleading. The real capability lives in the deps.

Changes

• Collect dependency manifests during the scan (requirements.txt, pyproject.toml, *.csproj, azure.yaml; lockfiles excluded). Stored in module state so they never leak into the catalog JSON.
• fetchDependencySignals fetches those files (reusing the existing retrying fetchText), each capped at 3000 chars, 10000 chars total — generous enough that a normal manifest is never truncated, while bounding pathological upstream inputs so per-request cost stays predictable (well within the 182k TPM limit).
• Both prompts (generate + refine) now include a labelled "Dependency manifests (authoritative for the sample's real capability — prefer these over README wording)" block via the shared dependencyPromptSection helper. Falls back cleanly to README-only when no manifest is available.
• DISPLAY_NAME_GUIDANCE updated to surface real capabilities (MCP/RAG/Voice Live) only when the deps back them, with two capability-driven few-shot examples (04-foundry-toolbox → "MCP Toolbox Integration"; pipecat-webrtc → "Real-Time Voice Agent", NOT "Voice Live").
• Updated the AZURE_OPENAI_DEPLOYMENT fallback default from gpt-4o-mini to gpt-5.4-mini to match the deployed model.

Notes

• No new dependencies; reuses fetchText, callLLMForJson, and the shared guidance/prompt helpers (DRY).
• node --check passes; no type/lint errors.