Detect env-var-wired SaaS services

[nielsbosma]

Problem

SaaS services wired purely through environment variables / docker-compose environment: keys (no SDK/package dependency) were invisible to the analyzer. Concrete miss (from review of firecrawl): Supabase (SUPABASE_URL/SUPABASE_*_TOKEN) and Slack (SLACK_WEBHOOK_URL) are configured in docker-compose.yaml, and PostHog (POSTHOG_API_KEY) is a deliberately dependency-free capture client. specfy reports all three; we reported none.

Root cause

The env-var match source (dotenv / EnvVarNames) already exists end-to-end and the relevant detectors already carry the right prefixes (SUPABASE_, SLACK_, POSTHOG_). But ComponentDetector.ReadEnvVarNames only harvested keys from .env* files — it never read docker-compose environment: blocks, so compose-wired services produced no env-var signal.

What was implemented

• Extended ReadEnvVarNames in ComponentDetector.cs to also harvest env-var key names from docker-compose files (docker-compose*.yml/.yaml, compose*.yml/.yaml). Parses both the list form (- KEY=value, - KEY) and the map form (KEY: value) inside environment: blocks, tracking indentation so only keys within an environment block are collected (ports/other keys are excluded). Reuses the existing dotenv match source — no model or rule-engine changes, and no new YAML detectors were needed because PostHog/Supabase/Slack already declare dotenv prefixes.
• These remain weak (Low confidence) signals via the engine's existing dotenv-downgrade rule, so they stay out of hash slots (matches the suggestion's "confidence <= medium" guidance).

Tests

• New ComponentDetectorTests.Compose_environment_keys_become_env_var_names: end-to-end, writes a compose file and asserts SUPABASE_URL / SLACK_WEBHOOK_URL / POSTHOG_API_KEY / POSTHOG_HOST surface in EnvVarNames and that non-env keys (ports) do not leak.
• New RuleEngineTests.Detects_env_wired_saas_from_env_var_names theory: asserts Supabase/Slack/PostHog are detected from a single env-var name at Low confidence.
• Full suite: 99 passed / 99 total, 0 failed (95 baseline + 4 new). No snapshot changes.

Deferred / out of scope

• A dedicated envVars match facet (separate from the existing dotenv prefix facet) was not added: it is unnecessary here since the existing dotenv source already matches by prefix and all three target services are covered. Implementing a brand-new match source would have been a larger, higher-risk engine change for no additional detection coverage.
• Code-level string scanning (e.g. detecting a service from a hardcoded capture-endpoint URL with no env var at all) is not addressed; this PR covers the env-var/compose wiring path, which is the documented gap.