investigate-ci: tighten master gate and stop auto-allowing curl

- Gate flaky history on direct master rows: pull_request_number = 0 also matches
  release branches (head_ref='26.5') and merge-queue refs
  (gh-readonly-queue/master/...), so add head_ref = 'master' to the gate and the
  per-failure detail query.
- Remove the play.clickhouse.com curl allow from BOTH profiles. A wildcard curl
  allow cannot be constrained to read-only bodies (curl --data-binary @<file> or
  $(cat <file>) would exfiltrate local files to the public endpoint), so it is
  left prompt-gated everywhere. .claude/settings.json is back to master.

https://github.com/ClickHouse/ClickHouse/pull/107085

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

.claude/settings.investigate.json

@@ -1,5 +1,5 @@
 {
-  "//": "Locked-down profile for CI-failure investigation. Launch with: claude --settings .claude/settings.investigate.json. 'deny' wins over 'allow', so destructive actions are blocked even if some other settings file allows them. Read-only investigation commands run without prompts. WARNING: the node/python3 helper allows below execute repo-local scripts (.claude/tools/*) from the current checkout, and the Bash deny/allow list does NOT constrain child processes those scripts spawn — a PR under investigation could have modified them. Because of this, running this profile inside a throwaway git worktree on a trusted base-branch checkout of .claude/tools AND an environment with no credentials is REQUIRED when investigating untrusted PRs, not merely defense in depth.",
+  "//": "Locked-down profile for CI-failure investigation. Launch with: claude --settings .claude/settings.investigate.json. 'deny' wins over 'allow', so destructive actions are blocked even if some other settings file allows them. Read-only investigation commands run without prompts. WARNING: the node/python3 helper allows below execute repo-local scripts (.claude/tools/*) from the current checkout, and the Bash deny/allow list does NOT constrain child processes those scripts spawn — a PR under investigation could have modified them. Because of this, running this profile inside a throwaway git worktree on a trusted base-branch checkout of .claude/tools AND an environment with no credentials is REQUIRED when investigating untrusted PRs, not merely defense in depth. The play.clickhouse.com query is deliberately NOT allow-listed: a wildcard curl allow cannot be constrained to read-only bodies (e.g. curl --data-binary @<file> or $(cat <file>) would exfiltrate local files to the public endpoint), so it is left prompt-gated.",
   "permissions": {
     "deny": [
       "Edit",
@@ -40,7 +40,6 @@
       "Bash(node .claude/tools/fetch_ci_report.js:*)",
       "Bash(python3 .claude/tools/fetch_perf_report.py:*)",
       "Bash(python3 .claude/tools/analyze-assembly.py:*)",
-      "Bash(curl -sS https://play.clickhouse.com/?user=play:*)",
       "Bash(tar -xzf:*)",
       "Bash(tar -xf:*)",
       "Bash(tar -tzf:*)",

.claude/settings.json

@@ -23,7 +23,6 @@
       "Bash(grep:*)",
       "Bash(wc:*)",
       "Bash(jq:*)",
-      "Bash(curl -sS https://play.clickhouse.com/?user=play:*)",
       "Bash(which:*)",
       "Bash(strings:*)",
       "Bash(nm:*)",

.claude/skills/investigate-ci/SKILL.md

@@ -146,19 +146,22 @@ SELECT test_name,
 FROM checks
 WHERE check_start_time >= now() - INTERVAL 90 DAY
   AND test_name IN ( '<test1>', '<test2>', ... )
-  AND pull_request_number = 0
+  AND pull_request_number = 0 AND head_ref = 'master'
 GROUP BY test_name
 ORDER BY fail_7d DESC
 FORMAT TabSeparatedWithNames
 "
 ```
 
-**Gate on true master rows only — `pull_request_number = 0`.** Do *not* widen to
-`base_ref IN ('master','')`: that matches every PR targeting master (hundreds of nonzero PRs),
-so a failure in any *unrelated* PR — including a real regression that PR introduced — would make
-`fail_<window>d >= 1` here and send the investigated PR's own regression down the `FLAKY` path,
-skipping root-cause analysis. Direct `master` commits are the only rows that show the test is
-flaky independent of any PR.
+**Gate on direct `master` rows only — `pull_request_number = 0 AND head_ref = 'master'`.**
+`pull_request_number = 0` alone is not enough: it also matches release branches
+(`head_ref = '26.5'`) and merge-queue refs (`head_ref = 'gh-readonly-queue/master/pr-...'`), so a
+failure from an unrelated merge-queue PR or a release branch would inflate `fail_<window>d`.
+And do *not* widen to `base_ref IN ('master','')`: that matches every PR targeting master, so any
+unrelated PR's failure — including a real regression that PR introduced — would make
+`fail_<window>d >= 1` and send the investigated PR's own regression down the `FLAKY` path,
+skipping root-cause analysis. Only direct `master` HEAD rows show the test is flaky independent of
+any PR. (Add `AND head_repo = 'ClickHouse/ClickHouse'` if fork rows are a concern.)
 
 **Cross-PR failures are a separate, secondary signal.** If master rows are sparse, you may widen
 to other PRs as *corroboration* — never as the gate — and only after comparing failure modes (a
@@ -183,7 +186,7 @@ FROM checks
 WHERE check_start_time >= now() - INTERVAL 90 DAY
   AND test_name = '<test>'
   AND test_status IN ('FAIL','ERROR')
-  AND pull_request_number = 0
+  AND pull_request_number = 0 AND head_ref = 'master'
 ORDER BY day DESC
 FORMAT TabSeparatedWithNames
 "