Address review feedback on the build-failure-analysis pre-gate

.github/agents/build-failure-analyst.agent.md

@@ -61,7 +61,7 @@ The failed Azure DevOps build publishes **one binlog per build leg** (e.g. Linux
 > **These `binlog_*` functions are MCP tools** exposed by the `binlog-mcp` server. **Prefer calling them directly as MCP tools**, passing a JSON argument object (e.g. `binlog_errors` with `{ "binlog_file": "<path>" }`). A CLI wrapper is also mounted and allowlisted, so you may alternatively run it via the shell as `binlog-mcp <tool_name> --<arg_name> <value>` — e.g. `binlog-mcp binlog_errors --binlog_file <path>`. The binlogs are only readable through `binlog-mcp` (MCP tool or its CLI wrapper), not via `cat`/`ls` on `/data/binlogs`.
 
 1. For **each** path in `GH_AW_BINLOG_LIST`, call `binlog_errors { binlog_file: "<path>" }`. Concentrate your analysis on the leg(s) that actually report errors (each error has `{ severity, code, message, file, line, column, project }`).
-2. For the leg(s) with errors, call `binlog_overview { binlog_file: "<path>" }` for build configuration/context, and `binlog_warnings { binlog_file: "<path>", top: 10 }` when the failure looks like a `WarnAsError` promotion.
+2. For the leg(s) with errors, call `binlog_overview { binlog_file: "<path>" }` for build configuration/context, and `binlog_warnings { binlog_file: "<path>" }` when the failure looks like a `WarnAsError` promotion. `binlog_warnings` takes only `binlog_file` plus the optional `code` (e.g. `"CS0618"`) and `project` substring filters — there is no result-count parameter, so narrow with `code`/`project` rather than asking for a top-N.
 3. If a leg reports **no** errors from `binlog_errors`, that alone does **not** prove it compiled cleanly — a target can fail without emitting an MSBuild error, and non-MSBuild/process failures leave no error records. Before concluding a leg is clean, also check `binlog_overview` and look for failed targets / `OnError` handlers / process-termination clues (see **Defensive Behavior** below). Only when **every** leg shows no errors **and** no failed-target/process evidence has the build itself compiled cleanly. This workflow analyses **build** failures only: a clean compile means the pipeline failure is a **non-build** failure (most often a test / Helix / publishing stage), which is out of scope. In that case **post nothing** — call `noop` with a short reason (e.g. `"Build compiled cleanly across all legs; pipeline failure is in a non-build stage (test/Helix) — out of scope for build-failure analysis."`) and stop. Do **not** post a summary comment and do **not** invent code fixes.
 
 Pass each `binlog_file` verbatim from `GH_AW_BINLOG_LIST`. Because the MCP server is live, ask follow-up questions when these calls leave gaps — searching for specific error codes, listing targets that failed in a given project, or pulling task-level timing. Discover the full tool surface with `binlog-mcp`'s own `tools/list` (the MCP gateway exposes it automatically).