fix: a release that parses, and a sentence that reads

Adding `submodules: true` to the checkout step left two jobs with two
`with:` blocks. GitHub's workflow parser rejects a duplicate mapping key
outright, so the release lane could not be scheduled at all. It passed
review here because `yaml.safe_load` keeps the last duplicate silently —
the check now refuses duplicates the way GitHub does, and runs over all
three workflow files.

The --strict-config anchor started mid-clause, so the help it produced
read "fields that are this version of Dev does not recognize". It takes
the whole clause now. The branding test did not catch this because it
greps for the upstream name and never for coherence.

.hanzo/workflows/release.yml

@@ -42,7 +42,6 @@ jobs:
       - uses: actions/checkout@v4
         with:
           submodules: true
-        with:
           fetch-depth: 0
       - name: Next version, and the draft that will hold it
         id: v
@@ -195,7 +194,6 @@ jobs:
       - uses: actions/checkout@v4
         with:
           submodules: true
-        with:
           fetch-depth: 0
       - name: Tools
         run: |

patches/upstream.json

@@ -67,8 +67,8 @@
   },
   {
     "file": "tui/src/cli.rs",
-    "old": "not recognized by this version of Codex.",
-    "new": "this version of Dev does not recognize.",
+    "old": "fields that are not recognized by this version of Codex.",
+    "new": "fields this version of Dev does not recognize.",
     "count": 1
   },
   {
@@ -121,8 +121,8 @@
   },
   {
     "file": "exec/src/cli.rs",
-    "old": "not recognized by this version of Codex.",
-    "new": "this version of Dev does not recognize.",
+    "old": "fields that are not recognized by this version of Codex.",
+    "new": "fields this version of Dev does not recognize.",
     "count": 1
   },
   {