CI: remove the Documentation Team Review Requests workflow - #117019

…l is added

`Documentation Team Review Requests` starts one run per `pull_request_target`
event, but only one event per pull request arms real work: `opened` for an
internal pull request, `labeled` with `can be tested` for a fork. Every other
event produces a run whose two jobs both evaluate `if:` to false and conclude
`skipped`. GitHub delivers the arming event once and nothing re-sends it, so the
runs at one head are not interchangeable and a discarded arming run cannot be
recovered.

Two GitHub behaviours were discarding it. `cancel-in-progress: true` cancels a
run that is already executing, and the default `queue: single` cancels and
replaces a run that is merely pending. A pull request normally receives three to
six of these events within seconds of being opened, so both fired routinely: 36
of 300 runs in one 16.5 hour window ended `cancelled`, across four head
repositories.

The `${{ github.event_name }}` term in the group looks like the cause but is not.
It was added when the workflow had two triggers, `pull_request` for internal pull
requests and `pull_request_target` for forks, purely to stop
`cancel-in-progress: true` cancelling across the two paths. Consolidating both
onto `pull_request_target` left the term constant, which widened the blast radius
to the internal path as well, but the term was only ever a mitigation for the
cancellation and never a fix for it.

Measured loss: ClickHouse#116943, docs-only and merged, had its `opened` run 33207978258
cancelled one second later by a `pr-autogenerated-docs` label run that then
skipped. It merged with zero `review_requested` events although
`get_docs_teams_to_request` returns `integrations-ecosystem` and `docs` for its
changed files. The nine other docs pull requests in that window, whose arming
runs survived, all received their expected teams.

`cancel-in-progress: false` keeps a running arming run alive and `queue: max`
raises the pending limit from one to 100. The group is left alone, so a pull
request's runs still serialise and two of them never race the same
`requested_reviewers` call; letting duplicates run instead of cancelling them is
safe because the job submits only the teams that are not already requested.
Writing `cancel-in-progress: false` explicitly rather than deleting the line
keeps the coupling legible, since pairing `queue: max` with
`cancel-in-progress: true` is a documented workflow validation error.

The `ci/tests/` guard pins both settings. The `ci_tests` digest gains this
workflow because the job digests `./ci` plus four explicit extra files, not
`.github/`, so without that entry a change confined to this workflow would leave
the job a cache hit and the guard would never run on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Blargian, who authored the workflow and the mechanism behind it, asked for the
workflow to be removed so that documentation review requests can be driven from
an existing workflow instead of a separate one:
ClickHouse#117019 (comment)

This is an intentional removal rather than a fix. With the workflow gone no
documentation review request is made at all until that replacement lands. Today
they are made unreliably: 42 of the workflow's 300 runs in the 18 hours to
2026-08-29T07:45Z ended cancelled, and ClickHouse#116943 merged without either of the two
teams it was owed.

It supersedes the concurrency fix this branch previously carried, so the guard
under ci/tests and the digest entry pointing at the deleted file are reverted.
Both existed only to protect that file.

ci/jobs/scripts/team_review_requests.py and GH.request_team_reviews are left in
place. They hold the path-to-team routing and the request submission, so a
replacement invoked from an existing workflow can call them unchanged.