docs: search gitiles history before treating a Chrome fix CL as restricted (#53993)

A Gerrit change record can be access-restricted while the fix commit is
already public in git history and served unauthenticated by gitiles.
Teach chrome-release-cls a gitiles `+log ...&grep=<bug>` search (main +
branch-heads, Bug:/Fixed: footers, bounded ranges for chromium/src)
that works with or without a checkout, and state that RESTRICTED is
only valid once git/gitiles history is also empty. Have
chrome-release-verify step 3 re-resolve RESTRICTED/no-CL rows itself
(git fetch + log --all --remotes --grep, gitiles, fresh Gerrit query)
instead of inheriting the earlier verdict.


Claude-Session: https://claude.ai/code/session_013Z8MztJY8qTV43PRt5J6gx

Co-authored-by: Claude <noreply@anthropic.com>

.claude/skills/chrome-release-cls/SKILL.md

@@ -73,6 +73,18 @@ Drive it from `/tmp/cve_bugs.txt`. Prefer the **non-`[M1xx]`-prefixed** commit s
 
 For any bug with no local hit:
 - `git -C <repo> fetch origin` then re-search `--remotes` (fix may be newer than the checkout).
+- **Search gitiles history** — works with or without a checkout and needs no auth. Query `refs/heads/main` plus the release's branch refs (`refs/branch-heads/<Chromium branch number>` for `chromium/src`, `refs/branch-heads/<V8 major.minor>` for `v8/v8`, likewise `angle/angle` and `skia` on chromium.googlesource.com, and `pdfium.googlesource.com/pdfium`, `dawn.googlesource.com/dawn`, `aomedia.googlesource.com/aom`). The response starts with a `)]}'` line; gitiles `grep` is a substring match over the whole commit message, so check the hit's `Bug:`/`Fixed:` footer:
+  ```bash
+  gitiles_grep() {  # gitiles_grep <host> <repo> <ref> <bug>   e.g. chromium v8/v8 refs/branch-heads/15.2 558734727
+    curl -s "https://$1.googlesource.com/$2/+log/$3?format=JSON&n=50&grep=$4" | tail -n +2 | python3 -c '
+  import sys, json, re
+  for c in json.load(sys.stdin).get("log", []):
+      if re.search(r"^(Bug|Fixed):.*\b" + sys.argv[1] + r"\b", c["message"], re.M):
+          print(c["commit"], c["message"].splitlines()[0])
+  ' "$4"
+  }
+  ```
+  For `chromium/src` **always bound the walk with a range** — an unbounded grep over its full history times out (HTTP 502): pass `refs/branch-heads/<previous milestone's branch>..refs/branch-heads/<this branch>` and `refs/branch-heads/<this branch>..refs/heads/main` as the ref (branch number = third component of the Chrome version, e.g. 8010 for 153.0.8010.x; the previous milestone's is in `https://chromiumdash.appspot.com/fetch_milestones?mstone=<N-1>`). The sub-repos are small enough to walk unbounded (a few seconds). A hit gives the sha, the ref, and (from the commit message) the `Reviewed-on:` CL — report it as the fix even if Gerrit refuses to show that CL.
 - Query Gerrit directly: `curl -s "https://chromium-review.googlesource.com/changes/?q=bug:${BUG}&n=10" | tail -n +2 | python3 -m json.tool` (also try `skia-review`, `pdfium-review`, `dawn-review`, `aomedia-review`).
 - **`b/` bug format (Skia, Graphite, Dawn):** These repos reference bugs as `b/<id>` in commit messages rather than `Bug: <id>` footers. The Gerrit `bug:` query will return nothing. Use `message:<id>` search instead:
   ```bash
@@ -87,7 +99,8 @@ For any bug with no local hit:
   print(d.get('cherry_pick_of_change', 'none'))
   "
   ```
-- If still nothing and the bug was reported very recently (especially by "Google Threat Intelligence" or marked in-the-wild), the CL is likely still access-restricted — report it as such rather than guessing.
+- **A CL that is restricted in Gerrit may still be public in git.** The change record and the repository have separate ACLs, and the change often stays hidden for days after the commit has landed on main and the branch-heads. So RESTRICTED is only a valid verdict once git history (local, `--remotes` after a fetch) *and* gitiles have both come up empty — a Gerrit miss on its own is not enough.
+- If still nothing and the bug was reported very recently (especially by "Google Threat Intelligence" or marked in-the-wild), the CL is likely still access-restricted — report it as RESTRICTED rather than guessing, and flag it for a re-check (restrictions are commonly lifted within hours).
 
 ### 4. Special cases
 

.claude/skills/chrome-release-verify/SKILL.md

@@ -39,6 +39,8 @@ For each bug, three checks against the **synced** repo:
 
 Any hit ⇒ IN-TREE. All empty ⇒ NEEDS-BACKPORT.
 
+Rows that step 1 (or an upstream triage report you were handed) left as **RESTRICTED / no public CL** are not inherited — re-resolve them here before classifying. Run `git -C "$repo" fetch origin` and `git -C "$repo" log --all --remotes -E --grep="(Bug|Fixed):.*\b${bug}\b" --format='%h %s'`, the `chrome-release-cls` skill's `gitiles_grep` on `refs/heads/main` and the branch-heads refs of `chromium/src`, `v8` and the component's repo, and a fresh Gerrit `?q=bug:<id>` / `?q=message:<id>` query. The Gerrit change record is often restricted while the fix commit is already public in git, and restrictions lift during a run, so an earlier RESTRICTED verdict is a hint, not a result. A row stays RESTRICTED only when all of those are empty; it is never IN-TREE by omission — list it separately in the report so a human can follow up.
+
 For each NEEDS-BACKPORT CL, also fetch its file list (`/changes/<proj>~<cl>/revisions/current/files`) and **skip** if every file is under `chrome/browser/`, `chrome/android/`, `ios/`, or `components/**/android/` — Electron doesn't compile those.
 
 Report the table now (`CVE | Sev | Bug | Component | Verdict | CL`) and the proposed backport set; get user sign-off before continuing.