Catch Doppler config drift before every GitHub release

Build a pre-release config drift checker that runs on every production release we cut in GitHub.

Trigger: an incoming webhook from GitHub on the release event, only when the action is published. The webhook payload tells us which repository the release is for and gives us the release id and tag name.

Inputs the user should configure as workflow parameters: a JSON map from GitHub repository (in owner/name form) to the matching Doppler project name, the Doppler config name to treat as production (default prod), the Doppler config name to treat as staging (default stg), the Slack channel id to post to, and a look-back window in hours for recent secret changes (default 24).

When the webhook fires, the agent should do the following:

1. Read the repository full name, release id, tag name, release name, and html_url from the webhook payload. If the repository is not present in the configured repo to project map, post a single Slack message to the release channel saying the release was skipped because the repo is unmapped, and stop.

2. Call GitHub Get a Release with the release id from the payload to confirm the release metadata and pick up the body of the release notes. Use this for context in the final report.

3. Look up the Doppler project for this repo from the configured map. Call Doppler List Secret Names twice: once for the production config and once for the staging config. Important: use List Secret Names, not List Secrets, so that the actual secret values are never fetched or held in the workflow.

4. Diff the two key sets and produce three lists: keys present in staging but missing in production, keys present in production but missing in staging, and the intersection (for context only, do not include in the report).

5. Call Doppler List Config Logs against the production config and filter to entries created within the configured look-back window (default last 24 hours). Extract the names of any secrets that were created, updated, or renamed in that window. These are the recently changed production keys.

6. Build a deploy-readiness report in plain English. The report should start with a clear verdict: safe to roll out, roll out with caution, or risky. Treat the release as risky if any production key was added in the look-back window with no matching staging key (a brand-new key production has never seen), or if any staging key with the look of an app secret is missing in production. Treat it as caution if there is drift but it is all benign (e.g. staging-only debug flags). Otherwise safe.

The report should then list, with bullets: keys in staging but missing in production, keys in production but missing in staging, and production keys updated in the last look-back window. Include a short summary line of how many keys were checked on each side, and link to the GitHub release html_url and the Doppler project so a human can dig in.

7. Post the report to the configured Slack release channel using Slack Send a Message. The message should be readable on its own (a non-engineer should be able to tell if the release is safe). After posting the main message, add a follow-up reply in the same Slack thread that links back to the GitHub release page and to the Doppler project URL.

Also post the same deploy-readiness summary as a comment on the GitHub release's discussion using GitHub Create an Issue Comment against the release's linked discussion number if the payload includes one. If the release has no linked discussion, skip the GitHub comment and only do the Slack thread follow-up.

Constraints: never call Doppler List Secrets or any operation that returns secret values; only List Secret Names and List Config Logs are allowed against Doppler. Do not echo any secret values in the report, even if the user later asks. Treat unknown repositories as a no-op with a Slack heads-up, not an error.

Background context: this is grounded in the standard Doppler plus GitHub Actions deployment pattern where teams continually fight production and staging environment drift. The whole point of this workflow is to catch that drift in the few seconds between cutting a release and rolling it out.