ci: put the Wrangler CLI version under version control

[FrameAutomata]

Closes #331 — "Real, we should lock down the version".

What was actually unpinned

Nothing in the repo said which Wrangler deploys tracewayapp.com. Neither website/package.json nor docs/package.json depended on wrangler, so the version was an implementation detail of cloudflare/wrangler-action:

action	default when wranglerVersion is unset
v3.15.0 (in use today)	DEFAULT_WRANGLER_VERSION = "3.90.0"
v4.0.0 (proposed in #344)	"4" — a range, so newest 4.x at deploy time

So today it is an exact version nobody chose, and after an action bump it becomes a floating one. Either way the tooling version on a production deploy path lives in someone else's repo.

The mechanism this uses

I read installWrangler rather than assuming (src/wranglerAction.ts on main, and confirmed the same code path is in v3.15.0's dist/index.mjs):

if (!config.didUserProvideWranglerVersion && installedVersion) {
    info("✅ No wrangler version specified, using pre-installed wrangler version …");
    return installedVersion;
}
if (config.didUserProvideWranglerVersion && versionSatisfied) { … }

An already-installed Wrangler wins when the input is absent, and is accepted when it satisfies the input. Both workflows already run npm ci in the same workingDirectory the action is given, so a devDependency lands exactly where the action looks.

That also means this composes with #344 in either merge order: #344 sets wranglerVersion: "3", an installed 3.114.17 satisfies it, so the lockfile still decides.

The change

website/package.json   + "wrangler": "3.114.17"   (exact)
docs/package.json      + "wrangler": "3.114.17"   (exact)
release-helm.yml       + wranglerVersion: "3.114.17"

release-helm.yml has no npm project to hold a lockfile, so it stays the one site that states the version — exactly, not as a bare major. "3" is a range the action re-resolves on every deploy, which is the drift the pin exists to stop.

The real gain is that this is the first version of this that a PR can test. npm ci && npm run build under the ci label now exercises the pinned CLI, on a path that otherwise has no pre-release validation at all.

Why 3.x and not 4

Locking down ≠ migrating. Wrangler 4 is a config migration — website/wrangler.toml is a Worker with main, [assets] and [observability.traces]; docs/wrangler.toml is assets-only — and it deserves its own change. That change is now possible to validate in a PR instead of by deploying to production, which it wasn't before this.

Verification

website $ npx wrangler --version   ->  3.114.17   (from package-lock.json)
docs    $ npx wrangler --version   ->  3.114.17

npm ci && npm run build passes in both.

Not run: the deploys themselves. As established on #331, workflow_dispatch is not a dry run on this path — it publishes to production Cloudflare.

🤖 Generated with Claude Code