Close a story from Facility, with a reason

The problem

A story can be triggered, planned, approved and shipped from Facility, but never abandoned. There is no verb that closes an issue.

FacilityGithubClient.updateIssue accepts state (services/api/src/github/client.ts:492-511) and no caller ever passes it. The one path that reaches it — the approved issue_update proposal (services/api/src/executors.ts:1907-1950) — sends title and body only.

So "this is not worth doing" is the one decision the operator has to leave the product to make, and the reason for it lands on GitHub with no trace in Facility's audit log — while every agent run, every approval and every rejection is recorded. That is backwards. The human decisions are the ones the record exists for.

What I propose

POST /v1/projects/:projectId/stories/:number/close with { reason: string, stateReason?: "completed" | "not_planned" }, audited as story.closed. It:

1. posts the reason as an issue comment attributed to the closing user — createIssueComment already exists (client.ts:586), and since GitHub has no field for a closing rationale, the comment is the record on that side;
2. closes the issue with state_reason — updateIssue needs the parameter added; not_planned is the one GitHub renders differently, and it is what won't do actually means;
3. updates the mirror optimistically the way executeIssueUpdate does (executors.ts:1941-1950), so the story reflects the change before the issues webhook echoes it back;
4. records the reason in the audit log.

In the UI: a Close story action in the story header beside the trigger buttons, with a required reason and a completed / not planned choice. Reopen is the obvious sibling and is nearly free — ship it too, or the button is a one-way door.

Two decisions worth settling explicitly.

Direct verb or HITL proposal? Direct. The proposal machinery exists so an agent's intent meets a human gate; a human closing an issue already is the gate. Routing it through Approvals would mean approving your own decision.

Which permission? issues:write currently governs platform issues — the watchtower health records in services/api/src/routes/v1/issues-audit-analytics.ts:104 — a different concept entirely. So either reuse repos:write, or introduce a distinct name. Worth choosing deliberately rather than colliding with an existing one.

And the timeline should carry it: issue_closed already exists as an item kind (apps/web/components/story/timeline.tsx) but shows neither the actor nor the reason. Both are available once we record them.

What I considered instead

• Reusing issue_update with state: "closed". It is a full title+body replacement whose payload has nowhere to put a rationale, and it pushes a human decision through a queue built for agents.
• Closing with no reason. Then it is a link to GitHub, not a decision the record can explain six months later. The reason is the point.

Related: #18, #39. Findings are against 5712bf8.

Start by tracing FacilityGithubClient.updateIssue in services/api/src/github/client.ts:492-511, createIssueComment at client.ts:586, and the approved issue_update path in services/api/src/executors.ts:1907-1950. Review the story timeline in apps/web/components/story/timeline.tsx and the referenced audit route. Done means the proposed close flow, reason, state reason, audit record, optimistic mirror update, UI action, and timeline details are consistently represented.