Standalone runtime sensor (secfoo sensor) as sidecar or host daemon #67

Part of #51. Today the sensors (#55, #56) write a local file. For live traffic, they need to report to a small companion process that runs next to the app, as a sidecar container, a host daemon or a Lambda extension, on Linux, macOS or Windows (#71), and forwards evidence to the user's secfoo server (#66).

app process ──(in-process probe, any runtime)──► unix socket / tcp loopback / named pipe ──► secfoo sensor ──HTTPS──► secfoo serve
                                                     (#73)                              (sidecar / daemon)      (#66)

The probe inside the app stays as thin as possible: count, sample, hand off. Everything heavier happens in the sensor process, so a slow network or a full disk can never reach the app's request path.

Usage:

# same API key as `secfoo cloud login`; server defaults to the same URL
SECFOO_API_KEY_FILE=/var/run/secrets/secfoo/api-key SECFOO_PROJECT=https://github.com/acme/payments-api \
SECFOO_APP=payments-api SECFOO_ENV=prod \
secfoo sensor run \
  --listen unix:///var/run/secfoo/sensor.sock   # or tcp://127.0.0.1:7461, npipe:////./pipe/secfoo-sensor

Responsibilities:

• Watchlist: fetch it from GET /api/runtime/v1/watchlist (poll with ETag, default 5 min) and write it where probes read it (SECFOO_WATCHLIST). Probes pick up changes without an app restart.
• Receive: the Probe ↔ sensor protocol and conformance kit (one contract for every runtime) #73 protocol from probes of any runtime, over a Unix socket, loopback TCP or a Windows named pipe (--listen, repeatable). Several app processes (gunicorn workers, Node cluster, Puma, PHP-FPM) can connect to one sensor, and so can several containers when it runs as a host daemon. Never listen on a routable address.
• Out-of-process collection for compiled binaries (Go, Rust and native binaries: inventory from build metadata, hits via uprobes #76): read embedded build metadata for inventory and, on Linux with the right capabilities, attach uprobes.
• Run as a service: secfoo sensor install registers a systemd unit, a Windows Service or a launchd agent.
• Aggregate: merge hits per (session, fingerprint, symbol, route), so a hot function sends one counter, not one line per call.
• Forward: batch to POST /api/runtime/v1/events every 5 s by default (--flush-interval). Retry with backoff.
• Buffer: when the server is unreachable, spool to disk up to --max-spool (default 50 MB). Drop the oldest batches first, and report drop counts in the heartbeat.
• Health: heartbeat every 30 s. Expose secfoo sensor status for liveness probes.

Rules (on top of the ones in #51):

• Explicit only. Nothing starts the sensor automatically: it isn't part of secfoo run, isn't installed with Secfoo, and isn't registered as a service unless the user runs secfoo sensor install themselves. When the API key, server or project is missing, it refuses to start with a clear message. It never falls back to a default account.
• Bounded memory and CPU. Document the defaults and enforce them.
• The probe must keep working when the sensor is down. It falls back to dropping (default) or to writing the Runtime evidence format, storage and secfoo runtime ingest #53 file (SECFOO_EVENTS_OUT).
• Sends only to the configured server. No other outbound connections.

Done when: tests cover every transport on Linux, macOS and Windows, several probes on one listener, the server being down (spool, then drain), a full spool (drop and report), and a watchlist update reaching a running probe. An end-to-end test runs a sample app with probe, sensor and secfoo serve and confirms evidence shows up within one flush interval.