v0.9.0

The bot holds its own request, and the thread decides

Two additions to the bot API, POST /api/v1/executions (docs/CONTEXT.md §4.57):

• review: { reason } holds the request for a reviewer whatever the datasource's policy would have let run, like a guardrail the bot raised itself. The reason (trimmed, at most 500 characters) is stored on the record, shown as a badge on the reviewers' page, in the Slack announcement and in what GET /api/v1/executions/[id] returns. 400 for a review without a reason.
• The announcement goes into the request's thread. The "waiting for approval" message with its Approve/Reject buttons is posted into the thread the request named (reply) as well as to SLACK_APPROVALS_CHANNEL, so the team that watches the thread decides where the request was made. Either copy settles the request; the other answers "already decided" when pressed later. A deployment with no reviewers' channel still announces in the thread.

Nothing else moved: who may decide is still the datasource's approverRoles (Slack users through a named role with user:slack:<id> members), two reviewers still means two, and the outcome still lands in the thread.

Image: ghcr.io/klinux/dbportal:0.9.0 · chart 0.1.34.