Gate secret-bearing and PR-code-executing workflows behind a maintainer /approve-ci command

## Motivation

Following #2184, looked at how much of our CI a pull request can reach before a maintainer has looked at it.

## The gap

GitHub's built-in "require approval for fork pull requests" setting only applies to `pull_request` runs from forks. It does not cover `pull_request_target`, which runs in the base repository context with access to repository secrets — a trigger GitHub's own docs flag as a known risk area. For that class of workflow we currently have no native approval step available.

## Proposal (v1)

A `/approve-ci` PR comment command:

- A maintainer comments `/approve-ci`; the command verifies them against a hardcoded maintainer allowlist and applies a `ci-approved` label
- A small set of workflows stays skipped until that label is present
- Approval is **sticky for the PR's lifetime** — once approved, later pushes run normally
- Bot-authored PRs (`asyncapi-bot`, `dependabot`) bypass the gate, reusing the bot-exclusion conditions these workflows already have

Deliberately minimal: easy to review, easy to revert, room to tighten later.

Start by reviewing the existing pull_request_target workflows and their current bot-exclusion conditions. Trace the /approve-ci comment command, maintainer allowlist, ci-approved label, and workflow skips; done means the named workflows stay gated until approval, approval remains sticky, and asyncapi-bot and dependabot still bypass the gate.

Written by the indexing model from the issue text.