feat(ci): substitute from the shared binary cache

[nikzen]

Every workflow builds the SDKs and the vodozemac bindings from source, while
the famedly Cachix the rest of the company uses sits unused next to it.

Reading. A step in steps.setup, so every generated workflow gets it. It
may fail without failing the workflow: a cache out of reach should cost a run
its time and not its result.

Writing. Only main and tags. A pull request and a merge queue entry both
build what a branch decided, and a run there that could write would let any
branch put a store path in front of every other repository's builds. The ref
decides this rather than the event name, which gets two cases wrong: a run
started by hand is not a push, and a push is whatever branch a repository
chose to run on.

Filling. Nothing here runs on main today, so the cache would have stayed
empty no matter who read it. populate-binary-cache builds what every
repository pinning these standards resolves against — the devshell, both SDKs,
the Rust toolchain and vodozemac — and, unlike every other workflow, fails
loudly when it cannot hand them over. Other repositories need nothing: the
option is empty by default, and what a workflow on main builds anyway is
already pushed by the step in setup.

x86_64-linux only here, though the option reaches all three systems. Darwin
bills ten times the minutes to move SDK archives Google already built, which
shortens nobody's wait; the one thing genuinely compiled there is vodozemac, at
24 seconds. aarch64-linux became a standard runner in private repositories in
January and costs no more than x64, so it is worth revisiting once we know
whether the arm64 image builds downstream compile anything the cache could hand
them.

vodozemac had to become an unconditional package to be built here at all: it was exposed only where a Dart project asked for it, and this repository has none.

Supersedes #50. Conflicts with #56, which moves the vodozemac module and adds an import next to this one's; whichever lands second wants a rebase.

Test plan

• nix flake check --all-systems, prek --all-files --stage pre-push
• every generated workflow carries the read step, and only the filling one
  carries it without continue-on-error
• skipPush is false only for refs/heads/main and refs/tags/*, so a
  pull request, a merge queue entry and a dispatch from a branch all read
• the run on main after merge fills the cache, and a later pull request
  substitutes vodozemac instead of building it

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6362449. Configure here.}

[tlater-famedly]

I don't think we need a separate workflow for uploads; the cachix action will implicitly fill the cache with any used artifacts, and the other workflows will be exercising those. Let's reduce the amount of workflow clutter.

#50 already covers enabling cachix, on the other hand, it's just blocked by the fact that our CI secrets don't currently work this way.

[tlater-famedly]

This doesn't work in public repos