chore(build): expand review-pr skill and add approve/reject-pr skills

Strengthen the review-pr agent skill to enforce the client's cross-repo
testing reality and zero-GC discipline, and add the companion approve-pr
and reject-pr skills.

review-pr:
- Add Step 2.7 cross-repo tandem-PR testing gate: this repo has no
  real-server e2e, so server-observable changes need a tandem questdb OSS
  PR (matching branch, cross-linked), HA changes need a questdb-enterprise
  PR, and kill -9 scenarios need Enterprise e2e-python tests. A required
  but missing tandem is Critical and forces the covered behavior UNTESTED.
- Add Step 2.6 cross-repo test coverage map (mandatory at every level); a
  row's covering test may be local or in a linked tandem PR.
- Enforce zero-GC on the ingestion hot path: rewrite Reviewer 3, add
  mandatory Reviewer 11 (adversarial performance & zero-GC), and make a
  single steady-state per-row allocation a blocking finding (14 reviewers).
- Spot whitebox tests and strongly prefer blackbox: flag reflection into
  internals, private-state assertions, and timing coupling that rot into
  flakes; require naming the public-API blackbox alternative.
- Add Step 4 test/tandem and zero-GC gates plus a rendered coverage map.

approve-pr / reject-pr:
- Post the conversation's review as an approving or change-request review.
- Gate approve on zero open Critical findings plus the zero-GC and
  test/tandem gates; auto-create the QUEUED FOR MERGE label if absent and
  guard the READY label removal, since this repo does not define them.

Author: bluestreak01

.pi/skills/approve-pr/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: approve-pr
+description: Approve the pull request for the currently checked-out branch. Posts the review from this conversation as an approving review and adds the "QUEUED FOR MERGE" label. Use after review-pr when you decide to approve.
+allowed-tools: bash read write
+metadata:
+  argument-hint: "[optional PR number or URL to override auto-detection]"
+---
+
+# Approve a QuestDB client pull request
+
+Approve the pull request for the branch that is currently checked out. This skill
+is meant to be run **right after `review-pr`** in the same conversation: it takes
+the review you just produced and posts it as an approving review. Do not
+re-review here — post the existing review.
+
+This repo (`java-questdb-client`) is a submodule of `questdb`. Approving the
+client PR does not approve any tandem PR — if the review required a tandem OSS or
+Enterprise PR (see the review-pr Step 2.7 gate), that PR must be approved
+separately in its own repo.
+
+Actions performed, in order:
+1. Post the review as the PR's review body (this is the "PR comment").
+2. Approve the PR.
+3. Add the `QUEUED FOR MERGE` label (creating it if this repo does not have it yet).
+
+## Step 0: Confirm the review actually clears the bar
+
+Only approve if the most recent `review-pr` report in this conversation has a
+verdict of **approve** with, per the review-pr Step 4 gates:
+- ZERO open Critical findings, and zero open correctness / concurrency /
+  resource findings;
+- the **Zero-GC gate** satisfied — no open steady-state (per-row / per-producer-call)
+  allocation or reachable algorithmic inefficiency on the ingestion path;
+- the **Test & tandem gate** satisfied — no UNTESTED Critical rows in the Step 2.6
+  coverage map, and every required tandem PR (OSS e2e / Enterprise / Enterprise
+  e2e-python) is present, linked, and running its suite.
+
+If any such finding is still open — including a required-but-missing tandem PR —
+do NOT approve. Tell the user the PR does not meet the bar and suggest
+`reject-pr`.
+
+- If no review report exists in this conversation, STOP and tell the user to run
+  `/skill:review-pr` first — do not approve unreviewed code.
+- Post the review verbatim; do not shorten or rewrite it.
+
+## Step 1: Detect the PR
+
+Auto-detect the PR from the checked-out branch. An explicit PR number/URL in the
+arguments overrides detection.
+
+```bash
+PR='<explicit PR number/URL from arguments, else empty>'
+[ -z "$PR" ] && PR=$(gh pr view --json number -q .number 2>/dev/null)
+if [ -z "$PR" ]; then
+  echo "No PR found for the current branch. Run 'gh pr checkout <n>' or pass a PR number."; exit 1
+fi
+gh pr view "$PR" --json number,title,author,headRefName,url,state,labels
+echo "Approving PR #$PR"
+```
+
+State one line to the user: which PR (`#number — title`) you are about to approve,
+then proceed.
+
+## Step 2: Write the review body to a file
+
+Write the review body to `/tmp/approve-pr-$PR.md` using the `write` tool (never
+inline it into a shell command — reviews contain backticks, quotes, and `$` that
+break shell quoting). The body is the full verbatim `review-pr` report.
+
+## Step 3: Post the approval
+
+```bash
+gh pr review "$PR" --approve --body-file /tmp/approve-pr-$PR.md
+
+# This repo may not have the label yet — create it idempotently before adding.
+if ! gh label list --limit 200 | grep -qx "QUEUED FOR MERGE"; then
+  gh label create "QUEUED FOR MERGE" \
+    --color f5e70d \
+    --description "Approved PR in the merge queue. Do not merge master into this PR." \
+    --force
+fi
+gh pr edit "$PR" --add-label "QUEUED FOR MERGE"
+```
+
+Notes:
+- GitHub does not allow approving your **own** PR. If `gh pr review --approve`
+  fails for that reason, fall back to
+  `gh pr comment "$PR" --body-file /tmp/approve-pr-$PR.md`, tell the user the PR
+  could not be formally approved because it is self-authored, and still add the
+  `QUEUED FOR MERGE` label.
+
+## Step 4: Confirm
+
+Report back in one or two lines:
+- PR number + title, "approved" posted (or the fallback used).
+- Whether the `QUEUED FOR MERGE` label was added (and whether it had to be created).
+- If the review required a tandem PR, remind the user to approve that tandem in its own repo.
+- The PR URL.

.pi/skills/reject-pr/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: reject-pr
+description: Reject the pull request for the currently checked-out branch. Posts the review from this conversation as a change-request review that tags the PR author, sets the PR to "changes requested", and clears the READY label. Use after review-pr when you decide to reject.
+allowed-tools: bash read write
+metadata:
+  argument-hint: "[optional PR number or URL to override auto-detection]"
+---
+
+# Reject a QuestDB client pull request
+
+Reject the pull request for the branch that is currently checked out. This skill
+is meant to be run **right after `review-pr`** in the same conversation: it takes
+the review you just produced and turns it into a blocking change-request on the
+PR. Do not re-review here — post the existing review.
+
+Actions performed, in order:
+1. Post the review as the PR's review body (this is the "PR comment"), tagging
+   the PR author.
+2. Request changes (sets the PR to the "changes requested" state).
+3. Clear the `READY` label (if present).
+
+## Step 0: Locate the review to post
+
+The body you post is **the most recent `review-pr` report in this conversation**
+(its Critical / Moderate / Minor / Downgraded / Coverage map / Summary output).
+
+- If no review report exists in this conversation, STOP and tell the user to run
+  `/skill:review-pr` first — do not fabricate a review.
+- Do not shorten or rewrite the review; post it verbatim. You only prepend the
+  author mention.
+- A required-but-missing tandem PR (review-pr Step 2.7) or any UNTESTED Critical
+  row in the coverage map is on its own sufficient grounds to reject — make sure
+  the posted review states which tandem is missing and what test it must add.
+
+## Step 1: Detect the PR
+
+Auto-detect the PR from the checked-out branch. An explicit PR number/URL in the
+arguments overrides detection.
+
+```bash
+PR='<explicit PR number/URL from arguments, else empty>'
+[ -z "$PR" ] && PR=$(gh pr view --json number -q .number 2>/dev/null)
+if [ -z "$PR" ]; then
+  echo "No PR found for the current branch. Run 'gh pr checkout <n>' or pass a PR number."; exit 1
+fi
+gh pr view "$PR" --json number,title,author,headRefName,url,state,labels
+AUTHOR=$(gh pr view "$PR" --json author -q .author.login)
+echo "Rejecting PR #$PR by @$AUTHOR"
+```
+
+State one line to the user: which PR (`#number — title`) and author you are about
+to reject, then proceed.
+
+## Step 2: Write the review body to a file
+
+Write the review body to `/tmp/reject-pr-$PR.md` using the `write` tool (never
+inline it into a shell command — reviews contain backticks, quotes, and `$` that
+break shell quoting). The first line must mention the author:
+
+```
+@<AUTHOR>
+
+<the full verbatim review-pr report>
+```
+
+## Step 3: Post the rejection
+
+```bash
+gh pr review "$PR" --request-changes --body-file /tmp/reject-pr-$PR.md
+
+# Clear the READY label only if present (avoids a spurious error; this repo may
+# not define the label at all).
+if gh pr view "$PR" --json labels -q '.labels[].name' | grep -qx "READY"; then
+  gh pr edit "$PR" --remove-label "READY"
+fi
+```
+
+Notes:
+- GitHub does not allow requesting changes on your **own** PR. If
+  `gh pr review --request-changes` fails for that reason, fall back to
+  `gh pr comment "$PR" --body-file /tmp/reject-pr-$PR.md`, tell the user the PR
+  could not be moved to "changes requested" because it is self-authored, and
+  still clear the `READY` label if present.
+
+## Step 4: Confirm
+
+Report back in one or two lines:
+- PR number + title, author tagged, "changes requested" posted (or the fallback used).
+- Whether the `READY` label was removed or was already absent.
+- The PR URL.