observability-installlisted

# Install a repo's minimum production observability One test decides everything here: **does a prod failure reach a human before a churned user's email does?** A deploy can verify green and then break at 2am, days after `/release-promotion`'s bounded watch ended - by design, since a standing cadence is the host's `/loop` or `/schedule` to own. What stands between that failure and silence is not a cadence: it is error tracking that captures the failure, a health endpoint that makes "up" checkable, and one alert channel that pages a person. Wire those three, prove they fire, record them. Read `.better-dev/overrides.md` first (`.better-dev/bin/bd-mem read overrides`) - a repo may already name its monitoring stack, or hold "we never instrument prod" as a recorded decision; honor either. ## Detect what already observes this repo Same discipline as `/guardrails-install`: detection is a premise, not a fact - report each as observed value plus where, and add only what is missing. - **Error tracking** - an error-tracking dependency in the manifest, its DSN-shaped env var named in the env template, the init call in the entry point. A dashboard mentioned in the README is a claim until the dependency and the init are seen. - **Health endpoint** - the recorded `deploy-health` rule (`.better-dev/bin/bd-mem recall "deploy"`), or a health/status route in the code. Fetch it once and read the status. - **Alert channel** - an alert rule in the tracker, an uptime probe pointed at prod