fix(vale): quote the verified aarch64 interpreter in the arm64 README

The arm64 README's glibc section was copy-pasted from the x64 one, asserting
`interpreter /lib64/ld-linux-x86-64.so.2` — the x86-64 dynamic linker — as a
verified fact about the arm64 binary. Checked against the pinned 3.17.1
Linux_arm64 archive (whose sha256 matches the manifest): the real string is
`ELF 64-bit LSB executable, ARM aarch64, dynamically linked, interpreter
/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped`. The minimum kernel
differs too (3.7.0, not 3.2.0), so both halves of the quoted string were wrong.

design.md scoped its verification to x86-64, which is what made the arm64 claim
unjustified; it now records both architectures' strings and notes that they
differ, so the next README does not inherit the same paste. The x64 README was
verified correct byte-for-byte and is unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3

Author: theCodeDrift

openspec/changes/add-vale-binary-packages/design.md

@@ -137,7 +137,7 @@ ast-grep's seventh is `win32-ia32`, and Vale publishes no 32-bit Windows asset,
 
 ### musl stays on the `PATH` fallback
 
-Upstream publishes no musl asset, so there is nothing to package for Alpine. That is not a naming detail: Vale's Linux build is **dynamically linked against glibc** — verified as `ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped` — so it is not a static Go binary and will not run on musl even if it were installed there. A musl host therefore falls back to a `vale` on `PATH`, and the linux packages' READMEs say so plainly rather than leaving a user to discover it as a loader error.
+Upstream publishes no musl asset, so there is nothing to package for Alpine. That is not a naming detail: Vale's Linux build is **dynamically linked against glibc** on both architectures — verified against the pinned 3.17.1 archives as `ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped` and, for arm64, `ELF 64-bit LSB executable, ARM aarch64, dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped` — so it is not a static Go binary and will not run on musl even if it were installed there. The two differ in interpreter path and minimum kernel, so each linux README quotes its own architecture's string rather than sharing one. A musl host therefore falls back to a `vale` on `PATH`, and the linux packages' READMEs say so plainly rather than leaving a user to discover it as a loader error.
 
 This matches the existing gap rather than widening it: `findSgBinary()` maps every Linux to `-gnu` today, so Alpine already falls through for ast-grep.
 

packages/vale-linux-arm64/README.md

@@ -44,11 +44,11 @@ the same digest upstream publishes in `vale_<version>_checksums.txt`.
 ## glibc, and why there is no musl package
 
 Vale's Linux build is dynamically linked against glibc — `ELF 64-bit LSB
-executable, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
-GNU/Linux 3.2.0` — so it is not a static Go binary and it does not run on
-musl-based distributions such as Alpine. Upstream publishes no musl asset, so
-there is nothing to package for those hosts; they fall back to a `vale` found
-on `PATH`.
+executable, ARM aarch64, dynamically linked, interpreter
+/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0` — so it is not a static Go
+binary and it does not run on musl-based distributions such as Alpine. Upstream
+publishes no musl asset, so there is nothing to package for those hosts; they
+fall back to a `vale` found on `PATH`.
 
 ## License