Post-merge incident process for an already-landed rented-loop PR found harmful

[JSONbored]

Problem: #4809's kill-switch and #4806's escalation path both cover a misbehaving, in-flight loop — stopping it and getting a human involved before it does more damage. Neither covers the scenario where a loop already completed and its PR already merged into a customer's live repository, and is only later discovered to be broken or harmful (a regression the target repo's own CI didn't catch, a subtly wrong fix, or something worse). #4805 (Terms of Service) itself frames the core risk explicitly: "An autonomous agent merging code into a paying customer's live repository... carries real liability exposure." A defined incident process for the pre-merge case (kill-switch) without one for the post-merge case leaves exactly the highest-liability scenario unaddressed.

Area: Safety / Support

Proposal: Define and build a post-merge incident process: how a customer or internal operator reports an already-merged rented-loop PR as harmful, what gittensory's obligations are (revert assistance, compute credit, notification), and how it's recorded for the audit trail and for feeding back into #4810's launch-readiness pilot criteria.

Deliverables:

• A documented, working post-merge incident path, distinct from but cross-referenced with the pre-merge kill-switch runbook (Kill-switch & incident runbook #4809).

Acceptance criteria:

• A simulated "already-merged PR found harmful" drill is handled end-to-end per the documented process, within a defined target time.
• The process produces an audit-trail entry, same as the kill-switch runbook does for pre-merge incidents.

Boundaries:

• Blocked on Kill-switch & incident runbook #4809 and Support & escalation path #4806 — this extends their scope to the post-merge case, it doesn't replace either.

---

Part of #4778.

[linear-code]

JSO-3685