docs: point the install commands at the release they install

[MongLong0214]

Every install line in all four READMEs pinned v0.8.2 — three releases behind
v1.0.1. Anyone following the documented command got a build without the hook
path fix (#693), the Codex plugin on non-Windows (#697), or anything else since.

The version appears twice per command (once in the raw URL, once as the
argument), five commands per file, four files. All twenty were stale together,
which is what happens when a release moves and the documentation that names it
does not: the two are edited in different changes and only one is required.

Verified rather than assumed: both raw URLs at the v1.0.1 tag return 200, and
the installer's own usage comment names v1.0.1.

[github-actions]

CommitLore — record lint

Trailers: clean — 2 commits in origin/main..3596fc1c74408d273beb8de2eae03cfbd1653a53
Active constraints: no paths changed in this range

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}

[MongLong0214]

Checked before approving, and the premise does not hold on current main.

README.md       v0.8.2: 0   v1.0.1: 5
README.ko.md    v0.8.2: 0   v1.0.1: 5
README.ja.md    v0.8.2: 0   v1.0.1: 5
README.zh-CN.md v0.8.2: 0   v1.0.1: 5

The install commands already point at v1.0.1. They were updated in the v1.0.1
bump (#692), which moved 38 pins across nine files — 20 of them these four
READMEs, because the installers and READMEs carry the tag in URLs that only
resolve once the tag exists, so they had to move in the same commit as the
version.

This PR reports changed_files: 0 with 2 commits, and its head branch
docs/install-commands-v1.0.1 is not in git ls-remote origin 'refs/heads/docs*'.

So there is nothing to review and nothing to merge. Not closing it — it is yours,
and the discrepancy might mean the branch was created against a different base
than I am reading.

Effect on the Reddit ordering

The reason to wait for this PR was that a tester following the documented command
would install v0.8.2 and report on the wrong build. That reason is gone: the
documented command installs v1.0.1 today.

#700 still gates it. A Windows tester meets exactly the case it fixes — Codex
MCP registration succeeds, the plugin step fails, and the installer reports
healthy and exits 0. A report saying "installed fine" from that state would be
describing a false success.