0.8.4 — the lockfile that was not there

The engine repository had no `bun.lock`. The instances had one, the engine did not — because the engine is not deployed, only pulled into instances, so it looked like a file with no use.

The consequence is that two clones of the same commit can build two different dependency trees. Not hypothetically: that is exactly what took production down the day before, when the tree ended up with two copies of the router and the site began rendering on the server and failing on hydration.

A missing lockfile is an error of the same class as failing to pin versions in a deployment configuration. The only difference is that it shows up later and for somebody else — for whoever clones the repository in three months and receives a set of packages nobody has ever tested.

So: `bun.lock` goes into the engine repository, and `overrides` in `package.json` force a single copy of `@tanstack/react-router`. The overrides are a second line of defence — the lockfile ought to be enough on its own, but this particular mistake cost a white page in production and there is no reason to rely on one mechanism.

In passing, a line entered the working conventions that looks like a triviality: `rm -f package-lock.json` before every commit. Tools are quite capable of generating a second package manager's lockfile while doing something else entirely, and two lockfiles in one repository is the same lottery again, merely well documented.

A fresh clone should be born resilient. That is the only state in which the version in the repository means anything at all.