v0.10.0

The approvals a bot already collected

From #17 by @lariskovski, thank you. A team whose chat bot runs its own approval flow had every write approved twice: once in the thread, then again on the portal's page (docs/CONTEXT.md §4.58).

• Service token: trustedApprovals (Security → Service tokens, off by default): the operator's statement that this bot's approval flow was reviewed and its word about approvers is accepted.
• POST /api/v1/executions: approvedBy: [{ reviewer, at }] (1–10 entries). From a token with the flag, a write on a datasource with writeApproval runs at once; the approvers are on the record and on the audit line as approved_by, apart from reviewer, so the trail says whether a decision was taken in the portal or declared from outside.
• What it does not do, by design: a guardrail, the bot's own review hold and a token with requireApproval still queue the request, whoever is declared. The portal does not count the approvers; a token without the flag that sends the field gets 400, refused rather than ignored.
• On top of the PR: an entry naming the requester (onBehalfOf) is refused, the same four-eyes rule the portal applies to its own decisions; and when a guardrail still holds the request, the declared approvers are shown on the reviewers' page and in the Slack announcement.

Image: ghcr.io/klinux/dbportal:0.10.0 · chart 0.1.36.