Merge remote-tracking branch 'origin/main' into garrytan/workspace-aware-ship

Rebumped v1.8.0.0 -> v1.11.0.0 (minor-past main's v1.10.1.0) using
bin/gstack-next-version — the same queue-aware path this branch introduces.
CHANGELOG repositioned so v1.11.0.0 sits above main's new entries
(v1.10.1.0 / v1.10.0.0 / v1.9.0.0).

Conflicts resolved:
- VERSION, package.json: rebumped to v1.11.0.0 (util-picked)
- bin/gstack-config: merged both lists (workspace_root + gbrain keys)
- CHANGELOG.md: hoisted v1.11.0.0 entry above main's new entries

Pre-existing failures in main (4) documented but not fixed in this PR:
1. gstack-brain-sync secret scan > blocks bearer-json (brain-sync tests)
2. no files larger than 2MB (security-bench fixture, already TODO'd)
3. selectTests > skill-specific change (touchfiles scoping)
4. Opus 4.7 overlay pacing directive (expectation stale after v1.10.1.0
   removed the Fan out nudge)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

model-overlays/opus-4-7.md

@@ -1,39 +1,18 @@
 {{INHERIT:claude}}
 
-**Fan out explicitly.** Opus 4.7 serializes by default. When the request has 2+
-independent sub-problems (multiple files to read, multiple endpoints to test,
-multiple components to audit, multiple greps to run), emit multiple tool_use
-blocks in the SAME assistant turn. That is how you parallelize. One turn with
-N tool calls, not N turns with 1 tool call each.
-
-Concrete example. If the user says "read foo.ts, bar.ts, and baz.ts":
-
-Wrong (3 turns):
-  Turn 1: Read(foo.ts), then you wait for output
-  Turn 2: Read(bar.ts), then you wait for output
-  Turn 3: Read(baz.ts)
-
-Right (1 turn, 3 parallel tool calls):
-  Turn 1: [Read(foo.ts), Read(bar.ts), Read(baz.ts)]  ← three tool_use blocks,
-                                                          same assistant message
-
-This applies to Read, Bash, Grep, Glob, WebFetch, Agent/subagent, and any tool
-where the sub-calls do not depend on each other's output. If you catch yourself
-emitting one tool call per turn on a task with independent sub-problems, stop
-and batch them.
-
 **Effort-match the step.** Simple file reads, config checks, command lookups, and
 mechanical edits don't need deep reasoning. Complete them quickly and move on. Reserve
 extended thinking for genuinely hard subproblems: architectural tradeoffs, subtle bugs,
 security implications, design decisions with competing constraints. Over-thinking
 simple steps wastes tokens and time.
 
-**Batch your questions.** If you need to clarify multiple things before proceeding,
-ask all of them in a single AskUserQuestion turn. Do not drip-feed one question per
-turn. Three questions in one message beats three back-and-forth exchanges. Exception:
-skill workflows that explicitly require one-question-at-a-time pacing (e.g., plan
-review skills with "STOP. AskUserQuestion once per issue. Do NOT batch.") override this
-nudge. The skill wins on pacing, always.
+**Pace questions to the skill.** If the current skill's text contains
+`STOP. AskUserQuestion` anywhere, pace one question per turn — emit the question as
+a tool_use, stop, wait for the user's response, then continue. Do not batch. A
+finding with an "obvious fix" is still a finding and still needs user approval
+before it lands in the plan. Only batch clarifying questions upfront when (a) the
+skill has no `STOP. AskUserQuestion` directive AND (b) you need multiple unrelated
+clarifications before you can begin. When in doubt, ask one question per turn.
 
 **Literal interpretation awareness.** Opus 4.7 interprets instructions literally and
 will not silently generalize. When the user says "fix the tests," fix all failing tests