Outcomes end at merge: add a post-merge window so "accepted" is joined to "held"

What the collector measures today

services/api/src/watchtower/outcomes.ts joins each agent PR to fate, acceptance (human squash-merge with evidence), review rounds, and fixup commits. oneShot = merged with zero change requests and zero human commits after the first bot commit on the PR branch.

Everything stops at merged_at. There is no signal for what happened to the change afterwards.

What that misses

• A revert of the merge commit (the sdlc page reports "0 production reverts"; nothing here measures it).
• A human commit or PR touching the same paths within N days of merge. Fixups landed in a separate PR are invisible to fixupCommits, so one-shot is overstated.
• A platform issue / CI-doctor fingerprint whose first appearance follows the merge and touches the same files.

The ROADMAP's definition of done, item 8, says deployment and production signals are joined back to the PR and outcome. The outcome record has nowhere to hold them.

Proposal

Add a post-merge evaluation to the nightly outcomes job:

• New columns on outcomes: held (bool, null until the window closes), post_merge_window_days (project setting, default 7), reverted_at, post_merge_human_commits (count of non-bot commits on the default branch touching the PR's changed paths inside the window), linked_incident_fingerprint.
• held = merged && !reverted && post_merge_human_commits == 0 && no linked incident.
• Analytics: report held next to accepted and oneShot in analytics.ts and the project page, with unassessed while the window is open.
• Keep the evidence path independent: read the default branch and revert commits from the GitHub API, never from Facility's own events, per the watchtower's rule 1.

Why

Acceptance measures whether a reviewer said yes. Held measures whether they were right. The learning agent's "silence outranks everything" rule applies here: a change that quietly needed a follow-up fix is the failure class most worth clustering, and today it never turns anything red.

I can open a PR against outcomes.ts and analytics.ts with tests if the shape is agreed. Filing first per CONTRIBUTING.

Start with the proposed changes in services/api/src/watchtower/outcomes.ts and analytics.ts, then read ROADMAP item 8 and CONTRIBUTING for the project’s constraints. Define the post-merge fields and window behavior, add tests as proposed, and verify that analytics and the project page report held or unassessed alongside accepted and oneShot.