fix(dart): keep the build directory out of the vodozemac bindings

[nikzen]

nix build --rebuild shows that two builds of famedly-vodozemac on a Mac are
never the same bytes. Nix builds in /nix/var/nix/builds/nix-<pid>-<random>,
and darwin has no sandbox to remap that to a constant, so the path reaches the
artefacts: 104 occurrences in the shared library, 212 in the static one, the
symbol suffixes LLVM hashes from a module's path, and LC_ID_DYLIB, which ld64
fills with the full output path when no install name is given.

Remapping the prefix leaves the static library reproducible down to the
byte and takes the shared one from ~1500 differing bytes to 48: the Mach-O
UUID and the ad-hoc signature over it. -Wl,-no_uuid would remove those at the
cost of ever symbolicating a crash, which is the worse trade.

The install name is worth fixing either way. The library announced its own
location as a build directory that stopped existing when the build finished.
Nothing reads it, since flutter_rust_bridge opens the file by the path it is
handed, but anything that linked against it would have kept that reference.

Inert on Linux: the hook is darwin-only, and the sandbox already mounts the
build directory at a constant /build. web.nix is a different artefact by a
different route and would need its own measurement.

Stacked on #56, where native.nix lives — the file this used to patch does not
survive that split. The derivation does: with this applied, both branches
produce the same store path.

Found while measuring what was worth putting in the shared binary cache (#59),
which it does not block.

Test plan

• nix flake check --all-systems, prek --all-files --stage pre-push
• nix build --rebuild on aarch64-darwin: the .a is byte-identical,
  the .dylib down to 48 bytes, no build directory paths left
• otool -l shows the install name under $out/lib
• a Dart project using the bindings still loads them

Made with Cursor

---

The stack

main ─┬─ #63  make room on the runner
      ├─ #59  substitute from the shared binary cache
      └─ #56  sign, describe and scan what we publish
            └─ #62  keep the build directory out of vodozemac  ←
                  └─ #61  tell a web build which build it is
                        └─ #64  let a project choose its vodozemac

#63 and #59 stand outside the chain and can land in any order. #59 and #56
both touch the vodozemac module, so whichever goes second wants a rebase.