Revert gh-aw pin from v0.71.4 back to v0.71.1

.github/aw/actions-lock.json

@@ -45,10 +45,10 @@
       "version": "v7.0.1",
       "sha": "043fb46d1a93c77aae656e7c1c64a875d1fc6a0a"
     },
-    "github/gh-aw-actions/setup@v0.71.4": {
+    "github/gh-aw-actions/setup@v0.71.1": {
       "repo": "github/gh-aw-actions/setup",
-      "version": "v0.71.4",
-      "sha": "f8495a686e66770ae977f82732f34d7340ee42a4"
+      "version": "v0.71.1",
+      "sha": "239aec45b78c8799417efdd5bc6d8cc036629ec1"
     },
     "microsoft/apm-action@v1.4.1": {
       "repo": "microsoft/apm-action",

.github/workflows/check-aw-updates.yml

@@ -10,7 +10,7 @@ jobs:
     name: Recompile lock files and open PR if changed
     runs-on: ubuntu-latest
     env:
-      GH_AW_VERSION: v0.71.4
+      GH_AW_VERSION: v0.71.1
     permissions:
       id-token: write
       contents: read

.github/workflows/gh-aw-docs-applies-to-sweep.md

@@ -9,7 +9,7 @@ inlined-imports: true
 imports:
   - gh-aw-fragments/formatting.md
   - gh-aw-fragments/rigor.md
-  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.4
+  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.1
     with:
       packages:
         - elastic/elastic-docs-skills/skills/authoring/applies-to-tagging

.github/workflows/gh-aw-docs-frontmatter-sweep.md

@@ -10,7 +10,7 @@ inlined-imports: true
 imports:
   - gh-aw-fragments/formatting.md
   - gh-aw-fragments/rigor.md
-  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.4
+  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.1
     with:
       packages:
         - elastic/elastic-docs-skills/skills/review/frontmatter-audit

.github/workflows/gh-aw-docs-openings-sweep.md

@@ -9,7 +9,7 @@ inlined-imports: true
 imports:
   - gh-aw-fragments/formatting.md
   - gh-aw-fragments/rigor.md
-  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.4
+  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.1
     with:
       packages:
         - elastic/elastic-docs-skills/skills/authoring/page-opening-optimizer

.github/workflows/gh-aw-docs-review.md

@@ -9,7 +9,7 @@ imports:
   - gh-aw-fragments/formatting.md
   - gh-aw-fragments/rigor.md
   - gh-aw-fragments/mcp-pagination.md
-  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.4
+  - uses: github/gh-aw/.github/workflows/shared/apm.md@v0.71.1
     with:
       packages:
         - elastic/elastic-docs-skills/skills/review/docs-check-style
@@ -207,7 +207,7 @@ Report only findings that are:
 
 Use line-level review comments when you can point to an exact changed line or nearby changed hunk. Keep each inline comment narrowly scoped.
 
-When helpful, include a concrete replacement sentence, frontmatter snippet, or markdown wording in the comment body. Prefer GitHub suggestion blocks when the proposed edit cleanly maps to the reviewed line or hunk and can be applied directly. Fall back to plain prose when the change is too large, crosses multiple distant hunks, or the exact replacement range is ambiguous.
+When helpful, include a concrete replacement sentence, frontmatter snippet, or markdown wording in the comment body. Prefer GitHub suggestion blocks only after passing the pre-output checklist below, and only when the proposed edit cleanly maps to the reviewed line or hunk and can be applied directly. Fall back to plain prose when the change is too large, crosses multiple distant hunks, includes protected substitution syntax, or the exact replacement range is ambiguous.
 
 The review comment safe output allows a maximum of 20 inline comments. Use that budget carefully:
 
@@ -218,10 +218,26 @@ The review comment safe output allows a maximum of 20 inline comments. Use that
 
 For inline comments with concrete replacements:
 
-- prefer one apply-ready GitHub suggestion over a prose description,
+- prefer one apply-ready GitHub suggestion over a prose description only after passing the pre-output checklist below,
 - keep the suggested replacement as small as possible while still fixing the issue, and
 - avoid suggestion blocks only when GitHub would not be able to apply them cleanly.
 
+Before creating any inline review comment, inspect the exact comment body you are about to send.
+
+If the comment body would contain a GitHub suggestion block and either the original reviewed line or the proposed replacement contains Elastic substitution syntax such as `{{...}}`, do not create the suggestion block. This is a hard rule. Safe-output sanitization can escape curly braces and corrupt substitutions when GitHub applies the suggestion.
+
+For these cases, use one of these alternatives instead:
+
+- Leave a prose-only inline comment with the exact replacement text outside a suggestion block.
+- If only part of the line needs changing, suggest only the substring that does not include `{{`, `}}`, or escaped variants such as `\{\{`.
+- If every useful replacement would include substitution syntax, do not include an apply-ready suggestion.
+
+Pre-output checklist for every `create_pull_request_review_comment` call:
+
+1. Does the comment body include a fenced `suggestion` block?
+2. Does the original reviewed line or suggested replacement include `{{`, `}}`, `\{\{`, or `\}\}`?
+3. If both are true, rewrite the comment before calling the tool so it has no `suggestion` block.
+
 Treat low-priority nits differently:
 
 - avoid nits unless they are grounded in the Elastic style guide or another explicit review rule in this workflow,