fix: assert which aws binary runs, because this script rewrites the whole config

Round 2 returned an addendum after the previous commit, having re-checked its
own instrument. Two findings, one blocking on the next --apply.

This machine carries two AWS CLIs on PATH: /opt/homebrew/bin/aws 2.34.53 and
/usr/local/bin/aws 2.11.15 (April 2023). configure.mjs called bare `aws`, so
PATH decided. That matters because update-distribution is a full replace and
botocore parses a config against its own model, dropping members it does not
know — an old CLI reads a lossy config and writes the loss back, and --if-match
cannot catch it because the ETag is genuinely current.

Measured, which the review could not do: the older model is missing nine
members, and E1OK7G98KNKUTA carries two of them — GrpcConfig on the default
behaviour and on /api/*, both {Enabled: false}. So a round trip through the old
CLI would write back the same effective value and change nothing observable
today. That is precisely why it needed a guard rather than a look: nothing
reports it when that stops being true.

The script now resolves the binary, prints it and its version as the first line
of output, and exits 2 below a floor before any AWS call. Verified both ways.

Second finding: entry (av) claimed "no client-side validation of any kind"
stood between the 182-character Comment and the API, from reading one
validate.py without naming which CLI it came from — and the other install is
frozen, so it is unchecked rather than confirmed. That is CLAUDE.md's named
shape. Both records now name the instrument and version and lead with the claim
that needs no qualification: the Comment reached the API and came back
InvalidArgument, so nothing stopped it on the CLI that ran.

The second install's model independently confirms FunctionARN max 108, its
pattern, and the 128 on both Comment members.

Nothing was applied to the distribution and nothing was deployed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5

AGENTS.md

@@ -957,6 +957,99 @@ never being raised again.
 
 # Change Log
 
+## 2026-09-04 (aw) — Round 2's addendum: this machine has two AWS CLIs 23 minor versions apart, the script called whichever `PATH` chose, and it rewrites the whole distribution config
+
+**Not a third round.** `adversarial-reviewer` returned an addendum to round 2
+after entry (av) was committed, having gone back to check its own instrument. Two
+findings, one blocking on the **next `--apply`** — which is why they are acted on
+rather than deferred. Entry (av) stands; nothing in it is retracted.
+
+---
+
+### 1. 🛑 The script called bare `aws`, and there are two
+
+`execFileSync('aws', …)` resolves from `PATH`. Measured 2026-09-04:
+**`/opt/homebrew/bin/aws` = 2.34.53** and **`/usr/local/bin/aws` = 2.11.15**
+(April 2023), both on `PATH`.
+
+**Why that is not cosmetic here.** `configure.mjs` reads the whole distribution
+config, mutates it, and posts the whole thing back — `update-distribution` is a
+**full replace** — and botocore parses a response against **its own** model,
+dropping members that model does not know. An old CLI therefore reads a lossy
+config and writes the loss back. **`--if-match` cannot catch it**: the ETag is
+genuinely current; only the parse was stale.
+
+**The reviewer could not measure the blast radius and said so. It is now
+measured.** Comparing the two installs' models for the same API version, the
+older one does not know nine members across `DistributionConfig`,
+`CacheBehavior` and `Origin` — and `E1OK7G98KNKUTA` **carries two of them**:
+
+```
+DefaultCacheBehavior.GrpcConfig = {"Enabled": false}
+CacheBehaviors[0].GrpcConfig    = {"Enabled": false}
+```
+
+⚠️ **Both are `{Enabled: false}`, which is the default — so a round trip through
+2.11.15 would write back the same effective value and change nothing observable
+today.** That is the whole reason it needed finding rather than noticing:
+**nothing would report it when that stops being true**, and the seven others
+(`ConnectionMode`, `VpcOriginConfig`, `CacheTagConfig`, `AnycastIpListId`,
+`TenantConfig`, `ViewerMtlsConfig`, `ResponseCompletionTimeout`) are one console
+change away from being present.
+
+**The fix.** The script resolves the binary, reads `aws --version`, and prints
+both as its **first line of output** — beside the two `resolved Managed-…` lines
+that already exist for the same reason. Below a floor it **exits 2 before any AWS
+call**. Verified both ways: `/opt/homebrew/bin/aws (2.34.53)` proceeds;
+`PATH=/usr/local/bin:$PATH` prints `/usr/local/bin/aws (2.11.15)` and exits **2**
+with **zero** `resolved Managed-` lines, i.e. no call was made. The floor is the
+version this was verified against — older fails loudly, which is the safe
+direction, and newer passes. **Lower it only with an entry here, never to make a
+run go through.**
+
+### 2. A universal claim from one unnamed instrument
+
+Entry (av) recorded that *"no client-side validation of any kind stood between
+that 182-character string and the CloudFront API"*, from reading
+`botocore/validate.py`. Neither the runbook nor the module said **which** CLI
+that was, and the second install is PyInstaller-frozen — its `validate.py` is not
+extractable, so it is **unchecked, not confirmed**.
+
+That is the shape `CLAUDE.md` corrected on 2026-09-01: *"no mechanism can X" is a
+claim about every mechanism, including the ones you did not enumerate*, and the
+preferred form was available. Both places now name the instrument and version —
+`aws-cli/2.34.53`'s bundled `validate.py` — say plainly that the other is
+unchecked, and lead with the claim that needs no qualification: **the
+182-character `Comment` reached the API and came back `InvalidArgument`, so
+nothing stopped it on the CLI that actually ran.**
+
+The same edit carries finding 3's carve-out into the module: every entry **with a
+cited AWS source** is enforced by the service and by nothing local; the two
+`[assumed]` `Name` entries are not known to be enforced at all.
+
+⚠️ **This does not weaken `PAYLOAD_LIMITS`** — the direct evidence for it is the
+failed call, not the validator read.
+
+### 3. Corroboration the addendum also produced
+
+The second install's model independently confirms four constants entry (av)
+sourced from one: `FunctionARN` `max: 108` and its pattern, and *"cannot be
+longer than 128 characters"* on **both** `Comment` members. Two independent
+models, same numbers.
+
+### 4. Verification
+
+`check` 0 · `build` 0 (23 pages) · `check:claims` 0 · `check:intake` 0 ·
+`og:proof` 0 · `lint` 0 · `router.test` 0 (30/30) · `policy-shapes.test` 0
+(53/53) · `spam-score.test` 0 (39/39) · minifier grep 1 (clean) · live dry run
+**0**, 3 changes, 0 skips · stale-CLI refusal **2**, before any AWS call.
+
+**Nothing was applied and nothing was deployed.** The distribution still shows
+`/api/*` on `b689b0a8-…`; the account still holds **1** custom response-headers
+policy (the orphan) and **0** origin request policies.
+
+---
+
 ## 2026-09-04 (av) — The second `--apply` got one policy further and failed on a 128-character cap that nothing local enforces; the orphan it left is reused by name, measured; the dry run gains the only pre-flight this script has; and §7's own record broke the table it lives in
 
 **Pouya's ruling of 2026-09-04**, after the second attempt: *"Fix: shorten BOTH